Некоторое время я работал над статьей о новинке Sun-а - архитектура процессора MAJC, который имел некоторые удивительные возможности для повышения скорости работы кода Java. MAJC это высокопроизводительный, много задачный, встраеваемый процессор, хотя несмотря на это были бы предложены полные компиляторы C/C++ и среды разработки, это из-за того, что Sun ожидал, что большинство разработчиков будут использовать Java, больше, чем другие языки. Поскольку рынок внедренных сред весьма чувствителен к соотношению цены и производительности, что как раз не является сильной стороной Java, то для моей статьи о MAJC я подумал, что следует разобраться в этом несколько глубже.

Введение в выполнение кодов Java и в статическую/динамическую компиляцию. Эта статья должна быть прочитана до чтения этого материала, если читатель не знает принципов компиляции и выполнения кодов виртуальной машиной.

Цели

Существует несколько причин, почему Java "исторически" медленнее, чем C (если сравнивать чистую производительность). Для начинающих в кратце - Java оптимизируется во время выполнения кода, а не во время компиляции, и при этом стандартные библиотеку должны работать одинаково на всех платформах, что требует дополнительного уровня программного обеспечения. Java еще и относительно новая технология - не забывайте, что прошло много времени, пока компиляторы C стали хороши (к тому же они и сейчас постоянно улучшаются) - и тоже самое было и с C++. На вершине производительности стоят всегда низкоуровневые программы, использующие маленькие библиотеки или не использующие их вовсе. На пути оптимизации есть несколько трудностей и в Java - любой доступ к массиву проверяется на легальность (с проверкой границ массива), стандартная строковая библиотека использует 16-bit Unicode вместо 8-bit ASCII, что означает, что все строки в два раза больше, все массивы должны быть инициализированы, динамическое распределение памяти работает через главный сборщик мусора, никакие мейнстримы центральных процессоров пока не используются ни в каких оптимизаторах, а так же имеются трудности с реализацией специфических мультимедийных инструкций. В теории, сборщик мусора и динамическая оптимизация могут быть преимуществом сами по себе, а большая часть трудностей, описанных выше, может быть оптимизирована хорошим оптимизатором - исключая 16-bit представление строк.

Эта статья не претендует на полное сравнение скорости работы Java и C, поскольку это не так-то уж и легко сделать.

Методы тестирования

Все тесты были запущены на моем персональном компьютере (Athlon 500 на Asus K7M МБ с 128MB PC100 SDRAM), с Windows 98SE - Windows в момент написания статьи была системой с наибольшим числом доступных современных JVM, так же, впрочем как и по выбору компиляторов C. Для каждой из программ, было произведено несколько запусков тестов с увеличением сложности или размера, кроме этого, каждый из тестов запускался 5 раз, самые большие и маленькие результаты отбрасывались, а конечным результатом было среднее, между оставшимися тремя. Для каждого теста было осуществлено два быстрых пробных теста для того, что бы определить, сколько нужно совершить циклов, что бы время работы программы было примерно равно 10 секундам, это нужно для того что бы уменьшить погрешность при измерении времени. 10-и секунд так же достаточно, что бы виртуальная машина полностью заоптимизировалась, так же в это время осуществляется само подстройка кода, для того, что бы он работал быстрее (оптимизация кода). Я не удовлетворен работой в Windows 98 таймера (точность), вычислительных потоков и многозадачности, обработкой прерываний (намного хуже, чем под Solaris, FreeBSD и Linux), но результаты в основном были предсказуемы и стабильны, и зачастую не было больших различий во всех пяти запусках.

Пояснение результатов тестирования: производительность дана относительно базового теста, а это программа на C откомпилированная с одной простой оптимизацией. Для каждого из тестов было произведена нормализация относительно 100 полученного из базового теста. Результат равный 110 должен быть быстрее на 10%, чем базовый тест, а результат в 90 должен быть на 10% медленнее. Другие тесты производились с компиляцией C с использованием более агрессивной оптимизацией, с использованием тех же правил, для всех остальных программ C. Ключи к графикам (легенда)