Сравнительное тестирование производительности платформ .Net, Java и Mono

С оптимизациями попробуйте. У меня они дали прирост процентов 30, повлияв лишь на скорость первоначального запуска (JIT тупит раз в 5 дольше). Для веба и разных демонов их хорошо использовать.

призываемся…
тыкаем пальцем в тест (попадаем в Div10Test)…
копируем к себе…

запускаем java -client:
405076.469 ops/msec (4 threads)

запускаем java -server:
8597842842313.524 ops/msec (4 threads)

отзываемся…
;)

А вы не читали доклада Алексея Шипилёва с JavaOne? :)

«Those of you, who think you know everything about Java, annoy those of us, who do» ;)

Там же был и кандидатский минимум, который должен иметь человек, чтобы делать аналитические выводы из результатов бенчмарка.

«Прогреваем JVM для математических операций»…

Прогоняется, то прогоняется. Только нужно запустить тест достаточный, что бы все разогрелось и выкинуть его результаты. Это достаточно просто понять. Еще если например тестируется веб-приложение, то все кеши желательно отключить и так далее.

Вы же не хотите сказатЬ, что знать эти опции достаточно, чтобы судить о результатах бенчмарка, правда?

Если я не ошибаюсь, в .Net аналогичный подход, сначало приложение компилится в MSIL, а потом при первом запуске при помощи CLR интерпритиется и компилится в native code. Хотя может что-то напутал, в нутрах .Net не силен.

Насколько я понимаю, считать надо не

i++

, а

AtomicInteger.getAndIncrement()

а то))
она ещё умеет ассемблерные вставки в байт код на лету вставлять ;)

Конечно надо. И любой рантайм, имеющий адаптивный JIT, поддерживающий де-оптимизации, профили нагрузки и прочее, надо.

только если .NET хуже :)

тогда можно подождать Java 8 ;-))))) ну даже если и сравнивать Java 6 и .Net 4.0 то нужно, как я выше сказал, параметры для памяти правильно выставить… да и для более реалистичной картины тестов на производительность нужно создать правильную среду… хотя бы чтобы вовремя тестов не работали другие программы, поменьше сервисов были запущены и тд… да мне сложно сказать, что на виртуальных машинах можно получить реальную картину…

«можно» или «можно было»?

Никто случайно не мониторит как идет разработка моно после продажи Novell?

кстати, интересно было бы почитать про опыт применения моно в хайлоаде

Разработчики высокопроизводительных систем знают что производительность надо мерить профайлером и на реальном коде. Разработчики высокопроизводительных систем знают что важны именно узки места, а не 0.00001% времени исполнения. Разработчики высокопроизводительных систем знают что во-многом важна не скорость работы, а знание платформы, чтобы быть уверенным в сроках и быстро исправлять внезапно появившиеся ошибки. Продолжать?

Хотя… Даже если попросите, продолжать не буду. Пока люди думают, что подобные тесты хоть что-то значат и могут как-то повлиять на выбор платформы, стоимость услуг именно разработчиков будет выше.

Про mono ncix'у отвечу тут (а то пишу раз в час): скорость скоростью, а как с надежностью? Насколько я помню, раньше проблема была именно в этом…

Руби?

Лучше сразу с Brainfuck.

ark.intel.com/Product.aspx?id=27233
он как бы не поддерживает x64
у самого такой проц в ноуте)

В принципе, Вы правы. Просто интересно было бы посмотреть, скажем, реализацию какого-нибудь крупного проекта настолько идентично, насколько это возможно, на двух языках. С замерами производительности. Насчёт данного тестирования — интересно было бы ещё посмотреть скорость работы с файлами, отсортировать там произвольный файл или что-нибудь наподобие.

Вопрос снят)

объясняю: Andrew>9000 говорит, что ему интереснее было бы почитать про совместимость mono и .NET чем про сравнение производительности

Да, спасибо, я про это и говорю.
Если со снижением скорости на 10% при переходе на mono многие готовы смириться, то неработоспособность готового решения может стать непреодолимым препятствием.

зачем вы ставите так вопрос? я такого не говорил.

дело в том, что на итоговую производительность оказывают влияние очень много разного
1. само измерение
— точно ли мы измеряем именно то, что измеряем, и не измеряем скорость измерения?
— операции внутри цикла точно сильно быстрее, чем цикл?

2. GC
— что именно мы измерили, время работы GC или время вычислений? (тут можно взять какой-нибудь oprofiler и посмотреть топ функций, есть ли там что-то похожее на сборщик мусора)

3. оптимизации и сам интерпретатор
— умеет ли он удалять неиспользуемые вычисления? если да, то в реальной жизни это может сильно помочь
— вытесняют ли используемые данные друг друга из кэша процессора? грубо говоря, обращаемся ли мы (интерпретатор или скомпилированный код) к данным сразу, или по ссылке, или по ссылке на ссылку, или по ссылке на ссылку на ссылку?
— правильно ли работает предсказатель переходов в циклах? разная работа предсказателя может приводить к разным результатам. на больших и на маленьких циклах результаты могут быть разными.

4. прочее
— строки изменяемые или неизменяемые? если неизменяемые, то создаётся повышенная нагрузка на GC (но в обмен, по-моему, достаются некоторые возможности для оптимизаций)

всё это очень сильно оказывает влияние на результат.
и есть несколько мнений. некоторые считают, что нужно измерять всё с учётом времени GC — мол, в реальных программах он работает, значит и в бенчмарках тоже должен быть. некоторые считают, что GC нужно мерить отдельно, а измерять нужно чистую скорость вычислений.

вы же все эти вопросы вообще проигнорировали.

сравнить скорость выполнения базовых функций — нормальный подход. автор сравнивает скорость выполнения непонятно чего именно, потому что чем меньше размер полезного кода, тем меньше его влияние на общее время и тем большее влияние оказывает факт наличия или отсутствия в компиляторе конкретной оптизации.
если бы кода было больше, было бы больше возможностей применить разные оптимизации и тем меньшее влияние оказывала бы любая отлдельно взятая оптимизация.
и время работы GC стоило бы замерить отдельно.

вы ни разу не задавались вопросом, почему при сравнении например процессоров или видеокарт приводят кучу тестов каких-то реальных приложений и игр, и не используют тесты «скорость вывода 1 текстуры размером 1 МБ», «скорость вывода буквы A на экран», «скорость работы i++»?

Тема «что тестируем» — вечна. Раз уж автор выбрал эти функции так и будет. У меня вопрос конечно только насколько он корректно это сделал. Хороший показатель, что измерение правильное — точность цифр до десятых, сотых при повторном запуске.

Ассемблерный листинг пока привести затрудняюсь…

Вы правы, здесь я облажался:

 for (int i = 0; i < _iterationCount; ++i)
00000025  xor         edx,edx 
00000027  mov         dword ptr [ebp-4],edx 
0000002a  nop 
0000002b  jmp         00000031 
            {
                int x = i / 10;
0000002d  nop 
            for (int i = 0; i < _iterationCount; ++i)
0000002e  inc         dword ptr [ebp-4] 
00000031  mov         eax,dword ptr [ebp-4] 
00000034  mov         edx,dword ptr [ebp-8] 
00000037  cmp         eax,dword ptr [edx+0Ch] 
0000003a  jl          0000002D 
            }

Да, понимаю )

Я если что готов со стороны дотНет поучавствовать.

Более реальным — безусловно. Но будут названные выше вопросы к его корректности.
Что ж, может кто из Хабравчан возьмется за реализацию Вашей идеи)

Всё просто:
1,31406 — количество операций за микросекунду (умножьте на миллион получите количество операций в секунду)
1522,00 милисекунд — суммарное время выполнения микротеста (за текущий проход)
2e+08 — количество итераций (за текущий проход)

А, имелось ввиду в тесте

Да, вы безусловно специалист в мотивации отдельных людей или групп. :)

В целом, мне приятно, что технология которую я постоянно использую показывает такие результаты в одном из бенчмарков. Мне по настоящему это приятно и делает меня счастливее. :) Покажет в другом результаты хуже, станет грустнее.

Чего вы там своими оценками хотите показать мне абсолютно не понятно. Самоутвердится в том, что ваши оценки верны? Молодец, у вас все получилось. У данного бенчмарка тоже есть оценки, но они для меня более понятны чем ваши.

Про то зачем делают бенчмарки, вы правы. И даже как то странно думать что кто то может думать иначе.