Что быстрее C или Java с ее многочисленными ухищрениями, JIT-ами, HotSpot-ами и т.д. ? Что быстрее байткод или нативный уже откомпилированный под целевую платформу код?

Такими вопросами задались однажды подписчики телеконференции иерархии ФИДО Ru.Java летом 2000 года. Задались и решили проверить, а всегда ли нативный код быстрее (умнее, сильнее, выше и дальше :-) байткода выполняемого вирутальной машиной Java. Для этого были сформированы тестовые задачи и были проведены тесты. Как оказалось C даже не всегда вырывала победу и своего соперника.

Итак все по порядку.

Любому новичку будет ясно, что скомпилированный нативный код будет работать всегда быстрее "интерпретируемого" байткода, ведь последний должен еще и "переводиться" на понятный машине язык (без перевода он понятен только виртуальной машине). Но в действительности не все так как на самом деле, не будем вдаваться в технологические дебри реализаций и моделей вирутальных машин, а просто вспомним, что уже достаточно большое время в виртуальных машинах Java используются технологии JIT, а в некоторых даже и патентованные средства с названием HotSpot. Что же они делают? Из-за чего такой прирост производительности?

Эти технологии в общих чертах позволяют переводить интерпретируемый код для виртуальной машины в оптимизированный компилированный код целевой платформы. В некоторых реализациях эта процедура производиться не для всего кода, а только для тех критических участков, которые обычно и становятся "бутылочными горлышками" в производительности. Тем самым поднимается производительность и может экономиться время на компиляцию. Фокус так же заключается и в том, что производиться оптимизация относительно текущих параметров системы (ведь производиться компиляция во время выполнения, как говориться на лету) в отличии от компиляторов C, где код компилируется один раз и заранее нельзя угадать где и как он будет исполняться.

Чем проводилось тестирование:

Тесты Java:

Ack.java - функция Аккермана
Ack2.java - функция Аккермана
Iter.java - простая итерация
Iter2.java - простая итерация с оптимизацией для HotSpot Server.
Iter3.java - простая итерация с увеличенными в два раза "матрицами"
Sort.java - N^2 сортировка
Sort2.java - N^2 сортировка c увеличенной в два раза "матрицей"
Linpack benchmark - стандаpтный тест пpоизводительности на опеpациях с линейной алгебpой

Тесты C:

ACK.CPP - функция Аккермана
ITER.CPP - простая итерация
ITER3.cpp - простая итерация с увеличенными в два раза "матрицами"
SORT.CPP - N^2 сортировка
SORT2.CPP - N^2 сортировка c увеличенной в два раза "матрицей"
Linpack benchmark - стандаpтный тест пpоизводительности на опеpациях с линейной алгебpой

Тесты Дельфи:

ITER.PAS - простая итерация. Существует, так же второй вариант, несколько более быстрый ITER2.PAS.

Тесты "Паскаль":

Ack.pas - функция Аккермана

Результаты (цветом в таблице отделены различные испытания):

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

Т. к. в этом бенчмаpке ничего не пpоисходит кpоме pазмещения массивов и последyющих матpичных опеpаций, то вывод ясен: jit-compiler'ы пpоигpывают native-кодy именно на вpемени стаpта и, возможно, вpемени pазмещения пеpеменных. Некотоpое влияние на пpоизводительность оказывает pазмещение пеpеменных как static (в данном слyчае совеpшенно все pавно, объявлять ли пеpеменные и методы как пpинадлежащие к классy или объектy), опции оптимизации, использование байт-кода, выданного "чyжим" компилятоpом. Эти yсловия, однако, не меняют общей тенденции, котоpyю видно в таблице.

К сожалению, не все участники указали, конкретно, какая платформа использовалась, какие процессоры, сколько памяти и т.д. Поэтому следует сравнивать результаты, разделенные на группы, относительно друг друга.