Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 208
Такой вопрос, а в моно оптимизации включить не забыли? Запускать с ключом -O=all нужно.
Все параметры запуска специально приведены в статье
--desktop --gc=sgenС оптимизациями попробуйте. У меня они дали прирост процентов 30, повлияв лишь на скорость первоначального запуска (JIT тупит раз в 5 дольше). Для веба и разных демонов их хорошо использовать.
ну как я полагаю здесь целью теста было сравнения производительности платформы с настройками по умолчанию… так как у каждой среды есть параметры, которые выставляешь при запуске и которые оптимизируют процесс выполнения…
Знаете, эти параметры от дистра к дистру варьируются. В дебиане, например, какого-то хрена выключили AOT (ahead of time compilation) для сборок из GAC, и т. п.
это понятно… в таком случае для проведения тестов на производительность было бы корректно не просто написал код и запустил и замерять таймером… а для каждой задачи реализовать оптимальный код, учитывая специфику того или иного языка, потом не использовать обычный таймер для определения время выполнения, а специализированые инструменты профайлеры и выбрав соответствующий тип профайлинга… так как при выполнение кода, может выполняться и другие программы, которые и сжирают время…
да и насчет настроек оптимизации запуска, одни настройки могут оптимизировать работу со строками, а другие работу с математикой…
да и насчет настроек оптимизации запуска, одни настройки могут оптимизировать работу со строками, а другие работу с математикой…
Просто запускать моно без оптимизаций — это как запускать дебажный билд кода на плюсах, а потом его производительность с чем-то сравнивать. Десктопному софту более критично время запуска, чем эти 30% скорости управляемого кода (всё равно большую часть времени работают сишные либы и рантайм), поэтому дефолтно и выключили.
Предвижу холиварство, и реки ненависти:)
сейчас придут джависты и начнут обвинять вас в том, что вы не включили какую-нибудь оптимизационную опцию\не настроили ось должным образом и вообще это проплаченный MS'том тест. Let the holywar begins!
Начиная читать, я даже и не сомневался кто победит :)
Товарищи давайте не будем холиварить, гораздо лучше обсудить степень компетентности автора :) и параметры запуска заодно.
Язык и среду каждый выбирает сам либо по задаче, либо по душе
Язык и среду каждый выбирает сам либо по задаче, либо по душе
Результатом должна быть вторая статья, в которой будет измеряться скорость кода со всеми твиками и патчами :)
Товарищи давайте не будем холиварить, гораздо лучше обсудить степень компетентности автора :) и параметры запуска заодно.
В тред срочно призываются господа:
TheShade
Walrus
apangin
… прочие разработчики Java / JVM ;)
В тред срочно призываются господа:
TheShade
Walrus
apangin
… прочие разработчики Java / JVM ;)
Смотри-ка, минусуют потихоньку какие-то падлы :-D
призываемся…
тыкаем пальцем в тест (попадаем в Div10Test)…
копируем к себе…
запускаем java -client:
405076.469 ops/msec (4 threads)
запускаем java -server:
8597842842313.524 ops/msec (4 threads)
отзываемся…
;)
тыкаем пальцем в тест (попадаем в Div10Test)…
копируем к себе…
запускаем java -client:
405076.469 ops/msec (4 threads)
запускаем java -server:
8597842842313.524 ops/msec (4 threads)
отзываемся…
;)
Похоже, я вызывал джинов зря, черт. Я потратил одно желание :(.
;)
Notes:
Серверный JIT удалит нафиг не только деление, но и сам цикл. ;)
Меряем затраты на таймер. ;)
В других тестах (строки/коллекции) такого замечтельного эффекта так вот сразу и не добиться, но также много чего будет удалено.
Ааааа вот еще: мерять Hashtable — это клево. Я аж прослезился от ностальгии, ибо мало кто помнит временя Java 1.0 :)
Автор хорошо знает C#, но слабо Java.
Notes:
Серверный JIT удалит нафиг не только деление, но и сам цикл. ;)
Меряем затраты на таймер. ;)
В других тестах (строки/коллекции) такого замечтельного эффекта так вот сразу и не добиться, но также много чего будет удалено.
Ааааа вот еще: мерять Hashtable — это клево. Я аж прослезился от ностальгии, ибо мало кто помнит временя Java 1.0 :)
Автор хорошо знает C#, но слабо Java.
Для таймингов в дотНет наверное лучше пользовать Stopwatch
компетентность автора под большим вопросом, особенно в части java (сколько раз тесты запускал? JM тупо не прогрета, опции какие ?)
в общем совет автору, учите мат часть прежде чем делать тесты!!!
в общем совет автору, учите мат часть прежде чем делать тесты!!!
А вы не читали доклада Алексея Шипилёва с JavaOne? :)
«Those of you, who think you know everything about Java, annoy those of us, who do» ;)
Там же был и кандидатский минимум, который должен иметь человек, чтобы делать аналитические выводы из результатов бенчмарка.
«Those of you, who think you know everything about Java, annoy those of us, who do» ;)
Там же был и кандидатский минимум, который должен иметь человек, чтобы делать аналитические выводы из результатов бенчмарка.
Только «суровые челябинские мужики» умеет правильно проводить тестирование на скорость исполнения элементарных математических функций.
хотел тоже про Шипилева здесь написать, но вы опередили :)
«Прогреваем JVM для математических операций»…
В статье есть ответы на ваши вопросы:
Весь тест циклически прогонялся по 10 раз
-Xms32m -Xmx768mнадо как бы от 100 и больше
Прогоняется, то прогоняется. Только нужно запустить тест достаточный, что бы все разогрелось и выкинуть его результаты. Это достаточно просто понять. Еще если например тестируется веб-приложение, то все кеши желательно отключить и так далее.
Вы же не хотите сказатЬ, что знать эти опции достаточно, чтобы судить о результатах бенчмарка, правда?
Сорри, случайно, не попал на ту кнопочку — минусовал, но полностью поддерживаю. JavaVM — это почти интерпретатор при первом запуске — не раз проверялось. Код оптимизруется через некоторое время: JIT однако en.wikipedia.org/wiki/Just-in-time_compilation.
Да еще и тесты под вопросом. Не меряется ли скорость i++? Нужно оценить время отдельной операции. Если оно по порядку сравнимо с i++ то в чём суть тестов?
Ну и усреднение не лучший вариант. Считайте, что-то вроде квантилей — отбрасывайте сильно выпадающие результаты. 10 тестов тоже не понятно почему? Почему не 20? Или 30? И опятже почему среднее. Возможно даже худщий результат при грамотной обработке отображает больше информации. Вобщем советую почитать или просто подумать и повозится еще. Есть такой злой показатель как время переключения контекста — оно иногда на совсем мелких(<10ms) тестах портит некоторые показатели.
Все равно спасибо за проделаную работу.
Да еще и тесты под вопросом. Не меряется ли скорость i++? Нужно оценить время отдельной операции. Если оно по порядку сравнимо с i++ то в чём суть тестов?
Ну и усреднение не лучший вариант. Считайте, что-то вроде квантилей — отбрасывайте сильно выпадающие результаты. 10 тестов тоже не понятно почему? Почему не 20? Или 30? И опятже почему среднее. Возможно даже худщий результат при грамотной обработке отображает больше информации. Вобщем советую почитать или просто подумать и повозится еще. Есть такой злой показатель как время переключения контекста — оно иногда на совсем мелких(<10ms) тестах портит некоторые показатели.
Все равно спасибо за проделаную работу.
Та понятно — просто не берусь утерждать за то с чем не работал. Скажем так проведение тестов скорее всего более менее справедливое для обоих платформ. Но вопрос конечно достоверные-ли результаты — так может быть, что учитывая разные тонкости результат будет противополонжым, другим, а возможно и не сильно отличаться. Ну например JavaJIT оптимизирует, для примера, отдельные методы — правильно тестировать 100 раз запустатить в холостую и раз для теста метод делающий тест, то есть много тестов за раз. На самом деле почему делается 10000 или сколько там микротестов — опять же из-за того же разогрева кешей кода и данных, а также что бы устранить разные еффекты переключения задач. Но в любом случае есть подозрение, что табличный, например, синус вполне сравним с i++ и i < N.
Ну вот и выходит что будет тратится время еще и на компиляцию. А так конечно только Чак Норрис знает как на самом деле работает JVM :-)
Еще знают те господа, которых я призвал с тред выше :).
На самом деле, у JVM есть параметр, который указывает, скока раз должен выполниться метод в режиме интерпретации, прежде чем он будет скомпилирован в нативный код. По дефолну он, если я помню правильно, равен 1500 для клиентской версии JVM и 10.000 для серверной (что позволяет набрать больше статистики и построить более корректный load profile). Потому я и удивился, увидев каким малым числом параметров ограничился автор.
Предвижу что мне могут возразить в духе — «что это за платформа, где надо знать 100500 флагов, чтобы оттюнить ее». В ответ заранее скажу, что так оно и есть для любой сложной и производительной системы :)
На самом деле, у JVM есть параметр, который указывает, скока раз должен выполниться метод в режиме интерпретации, прежде чем он будет скомпилирован в нативный код. По дефолну он, если я помню правильно, равен 1500 для клиентской версии JVM и 10.000 для серверной (что позволяет набрать больше статистики и построить более корректный load profile). Потому я и удивился, увидев каким малым числом параметров ограничился автор.
Предвижу что мне могут возразить в духе — «что это за платформа, где надо знать 100500 флагов, чтобы оттюнить ее». В ответ заранее скажу, что так оно и есть для любой сложной и производительной системы :)
Вы еще забыли написать, что верны эти параметры для конкретно Sun(Oracle)-овской виртуальной машины, для других скорее всего другие. Кстати о птичках — есть еще много разных виртуальных машин и некоторые даже интересней чем мейнстрим и вполне работоспособные. (А о параметрах слышал, и многие использовал и GC отлаживал и чего только не делалось.)
Если я не ошибаюсь, в .Net аналогичный подход, сначало приложение компилится в MSIL, а потом при первом запуске при помощи CLR интерпритиется и компилится в native code. Хотя может что-то напутал, в нутрах .Net не силен.
Насколько я понимаю, считать надо не
i++AtomicInteger.getAndIncrement()всё попал под стадное чувство минуса)))
java настолько серьезна, что ее надо прогревать перед запуском!
Кстати, полностью поддерживаю. Учитывая, например, что в статье ни разу не упомянуты -server / -client JVM, используемые сборщики мусора… размер L1/L2 кеша процессора, и еще много других мелочей.
Про CLR я понял — а что про Java? Там -server используется или -client? В серверной JIT намного мощнее в плане эвристик оптимизации.
Про размер кеша? Ну если посмотреть детально код, посмотреть как распределяются объекты и сколька они суммарно памяти занимают… может быть.
А влияет скорее даже не конференция как таковая, а личное общение с разработчиками JVM.
Про размер кеша? Ну если посмотреть детально код, посмотреть как распределяются объекты и сколька они суммарно памяти занимают… может быть.
А влияет скорее даже не конференция как таковая, а личное общение с разработчиками JVM.
Вообще 3 ;-) Desktop, Concurrent, Server
Насколько я помню, Microsoft явно запрещал в лицензии на .NET 1/2 публикацию результатов тестов производительности — как у них с этим сейчас? Разрешили?
попробовали бы запустить Java не с -Xms32m -Xmx768m, а -Xms768m -Xmx768m… это если вы хотите протестировать на производительность, так как немало времени занимает выделение памяти… да и зависит от того какой вы профайлер использовали… ну как на меня то .Net 4.0 было бы лучше сравнивать с Java 7 (релиз которой будет через месяц)…
давайте тогда и .NET 5.0 подождем, чего уж там.
тогда можно подождать Java 8 ;-))))) ну даже если и сравнивать Java 6 и .Net 4.0 то нужно, как я выше сказал, параметры для памяти правильно выставить… да и для более реалистичной картины тестов на производительность нужно создать правильную среду… хотя бы чтобы вовремя тестов не работали другие программы, поменьше сервисов были запущены и тд… да мне сложно сказать, что на виртуальных машинах можно получить реальную картину…
Упомяну что на этих же тестах, .Net 4.0 была «совсем чуть-чуть немножко медленнее» чем 3.5, что меня немного разочаровало.
Не важно какой тест выиграл. Важно то, что эти тесты бесполезны. За исключением крайне специфичных проектов, коих и на 1% не наберется, эти данные совершенно ни о чем не говорят.
Кстати, думаю, что все эти операции ничего не стоят по сравнение с работой того же сборщика мусора.
Кстати, думаю, что все эти операции ничего не стоят по сравнение с работой того же сборщика мусора.
говорят как минимум о том, что mono уже можно рассматривать серьезно и без скидок
кстати, интересно было бы почитать про опыт применения моно в хайлоаде
Разработчики высокопроизводительных систем знают что производительность надо мерить профайлером и на реальном коде. Разработчики высокопроизводительных систем знают что важны именно узки места, а не 0.00001% времени исполнения. Разработчики высокопроизводительных систем знают что во-многом важна не скорость работы, а знание платформы, чтобы быть уверенным в сроках и быстро исправлять внезапно появившиеся ошибки. Продолжать?
Хотя… Даже если попросите, продолжать не буду. Пока люди думают, что подобные тесты хоть что-то значат и могут как-то повлиять на выбор платформы, стоимость услуг именно разработчиков будет выше.
Про mono ncix'у отвечу тут (а то пишу раз в час): скорость скоростью, а как с надежностью? Насколько я помню, раньше проблема была именно в этом…
Хотя… Даже если попросите, продолжать не буду. Пока люди думают, что подобные тесты хоть что-то значат и могут как-то повлиять на выбор платформы, стоимость услуг именно разработчиков будет выше.
Про mono ncix'у отвечу тут (а то пишу раз в час): скорость скоростью, а как с надежностью? Насколько я помню, раньше проблема была именно в этом…
Пост превосходства .net над жалкими конкурентами.
Нигде не увидел, было ли это под x86 или x64.
Спасибо за сравнение, актуальный вопрос)
Хотя, по-хорошему, конечно, производительность надо сравнивать на примере работы более менее крупных программ.
Но и так интересное сравнение)
Хотя, по-хорошему, конечно, производительность надо сравнивать на примере работы более менее крупных программ.
Но и так интересное сравнение)
на примере более-менее крупных программ встает вопрос корректности сравнения и правильности стиля программирования. Такая реализация, как сделал автор, на мой взгляд эти вопросы не снимает конечно окончательно, но делает менее актуальными.
В принципе, Вы правы. Просто интересно было бы посмотреть, скажем, реализацию какого-нибудь крупного проекта настолько идентично, насколько это возможно, на двух языках. С замерами производительности. Насчёт данного тестирования — интересно было бы ещё посмотреть скорость работы с файлами, отсортировать там произвольный файл или что-нибудь наподобие.
Думаю стоит добавить в похожие работы:
Ubuntu: Intel® Q6600® one core
Computer Language Benchmarks Game
Java 6 — server VS C# Mono
shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=java&lang2=csharp
Ubuntu: Intel® Q6600® one core
Computer Language Benchmarks Game
Java 6 — server VS C# Mono
shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=java&lang2=csharp
А все ещё хаят Microsoft :)
Немного удивлен результатами Mono. По некоторым тестам превосходит не только Java, но и .Net. Интересно, за счет чего бы это.
Более актуальным было бы тестирование на поддержку в mono разных экзотических функций из .NET.
Ну не WPF конечно, а что нибудь связанное с криптографией, например.
Ну не WPF конечно, а что нибудь связанное с криптографией, например.
вы различаете тесты на функциональность от тестов на скорость?
объясняю: Andrew>9000 говорит, что ему интереснее было бы почитать про совместимость mono и .NET чем про сравнение производительности
Эх этому mono еще бы комюнити побольше и .Net Community Process на подобие jcp.org/en/home/index а также работу на опережение совместимость с официальным компилятором — думаю это сильно бы подняло его конкрентоспособным по сравнению с Java.
Да, спасибо, я про это и говорю.
Если со снижением скорости на 10% при переходе на mono многие готовы смириться, то неработоспособность готового решения может стать непреодолимым препятствием.
Если со снижением скорости на 10% при переходе на mono многие готовы смириться, то неработоспособность готового решения может стать непреодолимым препятствием.
невероятно полезный тест. что он показывает?
скорость работы библиотечной функции «синус»? скорость работы int.ToString? зачем это вообще?
вы не пробовали хотя бы умножение матриц какое-нибудь бенчмаркить, или там линейный поиск в массиве, или что-нибудь из language shootout взять? такие тесты очень ругают, потому что они «are not the real-world tests». но у вас-то даже по сравнению с ними какое-то запредельное средневековье мрак мрак мрак
скорость работы библиотечной функции «синус»? скорость работы int.ToString? зачем это вообще?
вы не пробовали хотя бы умножение матриц какое-нибудь бенчмаркить, или там линейный поиск в массиве, или что-нибудь из language shootout взять? такие тесты очень ругают, потому что они «are not the real-world tests». но у вас-то даже по сравнению с ними какое-то запредельное средневековье мрак мрак мрак
а что библиотечные функции в реальных проектах не используюся?
зачем вы ставите так вопрос? я такого не говорил.
дело в том, что на итоговую производительность оказывают влияние очень много разного
1. само измерение
— точно ли мы измеряем именно то, что измеряем, и не измеряем скорость измерения?
— операции внутри цикла точно сильно быстрее, чем цикл?
2. GC
— что именно мы измерили, время работы GC или время вычислений? (тут можно взять какой-нибудь oprofiler и посмотреть топ функций, есть ли там что-то похожее на сборщик мусора)
3. оптимизации и сам интерпретатор
— умеет ли он удалять неиспользуемые вычисления? если да, то в реальной жизни это может сильно помочь
— вытесняют ли используемые данные друг друга из кэша процессора? грубо говоря, обращаемся ли мы (интерпретатор или скомпилированный код) к данным сразу, или по ссылке, или по ссылке на ссылку, или по ссылке на ссылку на ссылку?
— правильно ли работает предсказатель переходов в циклах? разная работа предсказателя может приводить к разным результатам. на больших и на маленьких циклах результаты могут быть разными.
4. прочее
— строки изменяемые или неизменяемые? если неизменяемые, то создаётся повышенная нагрузка на GC (но в обмен, по-моему, достаются некоторые возможности для оптимизаций)
всё это очень сильно оказывает влияние на результат.
и есть несколько мнений. некоторые считают, что нужно измерять всё с учётом времени GC — мол, в реальных программах он работает, значит и в бенчмарках тоже должен быть. некоторые считают, что GC нужно мерить отдельно, а измерять нужно чистую скорость вычислений.
вы же все эти вопросы вообще проигнорировали.
дело в том, что на итоговую производительность оказывают влияние очень много разного
1. само измерение
— точно ли мы измеряем именно то, что измеряем, и не измеряем скорость измерения?
— операции внутри цикла точно сильно быстрее, чем цикл?
2. GC
— что именно мы измерили, время работы GC или время вычислений? (тут можно взять какой-нибудь oprofiler и посмотреть топ функций, есть ли там что-то похожее на сборщик мусора)
3. оптимизации и сам интерпретатор
— умеет ли он удалять неиспользуемые вычисления? если да, то в реальной жизни это может сильно помочь
— вытесняют ли используемые данные друг друга из кэша процессора? грубо говоря, обращаемся ли мы (интерпретатор или скомпилированный код) к данным сразу, или по ссылке, или по ссылке на ссылку, или по ссылке на ссылку на ссылку?
— правильно ли работает предсказатель переходов в циклах? разная работа предсказателя может приводить к разным результатам. на больших и на маленьких циклах результаты могут быть разными.
4. прочее
— строки изменяемые или неизменяемые? если неизменяемые, то создаётся повышенная нагрузка на GC (но в обмен, по-моему, достаются некоторые возможности для оптимизаций)
всё это очень сильно оказывает влияние на результат.
и есть несколько мнений. некоторые считают, что нужно измерять всё с учётом времени GC — мол, в реальных программах он работает, значит и в бенчмарках тоже должен быть. некоторые считают, что GC нужно мерить отдельно, а измерять нужно чистую скорость вычислений.
вы же все эти вопросы вообще проигнорировали.
Повторюсь: мне кажется усложнение задачи (теста) приведет к возникновению большего количества вопросов, чем ответов. Чем проще и однострочнее тест, тем меньше вопросов в его автору из серии «а почему… а не ...». Сравнить скорость выполнения базовых функций (математических в том числе) — вполне себе нормальные подход для несложного теста.
В конце концов, тот же Top500 (немного не то, но все же) строится на основании результатов Linpack'а, а это — решение СЛУ (более сложная задача, но опирается на те же элементарные команды-операции).
В конце концов, тот же Top500 (немного не то, но все же) строится на основании результатов Linpack'а, а это — решение СЛУ (более сложная задача, но опирается на те же элементарные команды-операции).
сравнить скорость выполнения базовых функций — нормальный подход. автор сравнивает скорость выполнения непонятно чего именно, потому что чем меньше размер полезного кода, тем меньше его влияние на общее время и тем большее влияние оказывает факт наличия или отсутствия в компиляторе конкретной оптизации.
если бы кода было больше, было бы больше возможностей применить разные оптимизации и тем меньшее влияние оказывала бы любая отлдельно взятая оптимизация.
и время работы GC стоило бы замерить отдельно.
если бы кода было больше, было бы больше возможностей применить разные оптимизации и тем меньшее влияние оказывала бы любая отлдельно взятая оптимизация.
и время работы GC стоило бы замерить отдельно.
вы ни разу не задавались вопросом, почему при сравнении например процессоров или видеокарт приводят кучу тестов каких-то реальных приложений и игр, и не используют тесты «скорость вывода 1 текстуры размером 1 МБ», «скорость вывода буквы A на экран», «скорость работы i++»?
Почему, производители тех же процессоров наоборот пишут тесты специфические, зачастую не особо связанные с жизнью. Поэтому они и приводят такой параметр как «пиковая производительность», то есть полученная в идеальных условиях. Там как раз в основе лежат простые никак не связанные друг с другом операции (как с плавающей так и с фиксированной точкой).
Я не утверждаю, что у автора идеальные тесты для сравнения выбранных платформ или вообще чего-либо, но мне кажется что сравнивать на чем-то более масштабным было бы ещё менее корректно. Тут хоть понятно на уровне «эта строчка за столько то, эта дольше». Сравнивая целые программы вы упираетесь в ситуацию, когда чем больше ваша программа, тем непонятнее что вы сравнили, и тем больше может быть камней в ваш огород по специфике вашей реализации этой программы.
Я не утверждаю, что у автора идеальные тесты для сравнения выбранных платформ или вообще чего-либо, но мне кажется что сравнивать на чем-то более масштабным было бы ещё менее корректно. Тут хоть понятно на уровне «эта строчка за столько то, эта дольше». Сравнивая целые программы вы упираетесь в ситуацию, когда чем больше ваша программа, тем непонятнее что вы сравнили, и тем больше может быть камней в ваш огород по специфике вашей реализации этой программы.
> Почему, производители тех же процессоров наоборот пишут тесты специфические, зачастую не особо связанные с жизнью
да, это называется «маркетинг».
> Тут хоть понятно на уровне «эта строчка за столько то, эта дольше».
нет, не понятно. ещё раз говорю, что на время влияет куча всего. измерить время работы конкретной строчки вне её контекста практически невозможно или, уж во всяком случае, бессмысленно.
> чем больше ваша программа, тем непонятнее что вы сравнили
нужно сравнивать не самописные программы, а стандартные программы. скорость работы большого набора фильтров в фотошопе или GCC — неплохие варианты тестов для процессоров.
> и тем больше может быть камней в ваш огород по специфике вашей реализации этой программы.
поэтому есть три варианта: ловить камни, вообще ничего не делать, или измерить какую-нибудь абстрактную ерунду. автор топика пошёл по последнему пути и измерил какую-то ерунду.
да, это называется «маркетинг».
> Тут хоть понятно на уровне «эта строчка за столько то, эта дольше».
нет, не понятно. ещё раз говорю, что на время влияет куча всего. измерить время работы конкретной строчки вне её контекста практически невозможно или, уж во всяком случае, бессмысленно.
> чем больше ваша программа, тем непонятнее что вы сравнили
нужно сравнивать не самописные программы, а стандартные программы. скорость работы большого набора фильтров в фотошопе или GCC — неплохие варианты тестов для процессоров.
> и тем больше может быть камней в ваш огород по специфике вашей реализации этой программы.
поэтому есть три варианта: ловить камни, вообще ничего не делать, или измерить какую-нибудь абстрактную ерунду. автор топика пошёл по последнему пути и измерил какую-то ерунду.
По поводу маркетинга — в случае тестов самих производителей — да. В случае того же Linpack'а — да нет там никакого маркетинга, умный дядька написал — и всем понравилось.
По поводу урезания возможностей компилятора по оптимизации — естественно, ну а что делать. Ловить камни дело хорошее, но я пока не видел детального сравнения рассмотренных платформ, где камни были бы более-менее отловлены, и сам тест представлял бы собой какую-то полноценно-полезную или реальную программу. Максимум — решение какой-то простой задачи.
Просто всегда можно кинуть булыжник в стиле «пример неудачный, почему вы именно его выбрали?».
В общем, повторюсь, даже не думал декларировать идеальность этого теста, но сама попытка сравнения похвальна.
По поводу урезания возможностей компилятора по оптимизации — естественно, ну а что делать. Ловить камни дело хорошее, но я пока не видел детального сравнения рассмотренных платформ, где камни были бы более-менее отловлены, и сам тест представлял бы собой какую-то полноценно-полезную или реальную программу. Максимум — решение какой-то простой задачи.
Просто всегда можно кинуть булыжник в стиле «пример неудачный, почему вы именно его выбрали?».
В общем, повторюсь, даже не думал декларировать идеальность этого теста, но сама попытка сравнения похвальна.
нет, не понятно. ещё раз говорю, что на время влияет куча всего. измерить время работы конкретной строчки вне её контекста практически невозможно или, уж во всяком случае, бессмысленно.
Сорри, нажалась кнопка.
Я хотел сказать, что береш операцию сумирования например двух интов, ставиш туда задержку в час, и пробуеш написать оптимальный код. Бумс. Я думаю не получится. Обычно большую часть сокрости добавляют архитектурные решения, но это не повод делать сумирование интов в час. Если есть бесплатно возможность получить быстрое сумирование это же хорошо! Оно не помешает. В этом и суть таких тестов.
Я хотел сказать, что береш операцию сумирования например двух интов, ставиш туда задержку в час, и пробуеш написать оптимальный код. Бумс. Я думаю не получится. Обычно большую часть сокрости добавляют архитектурные решения, но это не повод делать сумирование интов в час. Если есть бесплатно возможность получить быстрое сумирование это же хорошо! Оно не помешает. В этом и суть таких тестов.
Тема «что тестируем» — вечна. Раз уж автор выбрал эти функции так и будет. У меня вопрос конечно только насколько он корректно это сделал. Хороший показатель, что измерение правильное — точность цифр до десятых, сотых при повторном запуске.
Кстати, нигде не увидел в посте… вы не ставити явно JVM -server? Вы уверены, что на вашей конфигурации железа она выбираются как дефолтная? Т.к. сравниваться по скорости и наворотам JIT-a с -client не комильфо
Впервые вижу как потенциально холиварный топик перетекает в адекватное общение специалистов своих областей, практически, без перехода на личности и троллинга. И это еще не вся Хабра подтянулась.
Автору спасибо, для себя сделал хоть какие-то выводы в плане Mono и порадовался за .Net в целом — всегда был далек от этой платформы. Было бы интересно посмотреть еще одну бенч-статью после твик-комментов по всем платформам. Вы разогрели интерес.
Автору спасибо, для себя сделал хоть какие-то выводы в плане Mono и порадовался за .Net в целом — всегда был далек от этой платформы. Было бы интересно посмотреть еще одну бенч-статью после твик-комментов по всем платформам. Вы разогрели интерес.
for (int i = 0; i < _iterationCount; ++i)
{
int x = i / 10;
}Переменная x не используется (аналогично в остальных тестах). Уверены, что компилятор не соптимизировал деление, выбросив его как ненужную операцию?
Строго говоря, следуют получить ассемблерный листинг того, что сгенерировал JIT, и проверить :)
Для Java вот полезная ссылка кстати по таким мелочам — blog.headius.com/2009/01/my-favorite-hotspot-jvm-flags.html. От автора JRuby.
Для Java вот полезная ссылка кстати по таким мелочам — blog.headius.com/2009/01/my-favorite-hotspot-jvm-flags.html. От автора JRuby.
Вот IL код представленного фрагмента:
деление на 10 присутсвует
.method public hidebysig virtual instance void
Do() cil managed
{
// Code size 35 (0x23)
.maxstack 2
.locals init ([0] int32 i)
IL_0000: ldarg.0
IL_0001: call instance void DotNetPerformance.SomeTest::StartTiming()
IL_0006: ldc.i4.0
IL_0007: stloc.0
IL_0008: br.s IL_0013
IL_000a: ldloc.0
IL_000b: ldc.i4.s 10
IL_000d: div
IL_000e: pop
IL_000f: ldloc.0
IL_0010: ldc.i4.1
IL_0011: add
IL_0012: stloc.0
IL_0013: ldloc.0
IL_0014: ldarg.0
IL_0015: ldfld int32 DotNetPerformance.SomeTest::_iterationCount
IL_001a: blt.s IL_000a
IL_001c: ldarg.0
IL_001d: call instance void DotNetPerformance.SomeTest::StopTiming()
IL_0022: ret
} // end of method Div10Test::Doделение на 10 присутсвует
Ассемблерный листинг пока привести затрудняюсь…
Вы правы, здесь я облажался:
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
}
то есть, деления не проиходит?
В остальных тестах точно такой же код, значит такая же оптимизация. Получается, что вы сравнили скорость выполнения операций на других языках с i++ на .NET, получили ошеломительные результаты и ввели кучу людей в заблуждение.
Ваше высказывание справедливо лишь для первых 4-х микротестов, div10, sqrt, sin и cos.
Интересно что дизассемблер студии показывает вызов sqrt, sin и cos:
а реально этого не происходит
Интересно что дизассемблер студии показывает вызов sqrt, sin и cos:
for (int i = 0; i < _iterationCount; ++i)
00000048 xor edx,edx
0000004a mov dword ptr [ebp-14h],edx
0000004d nop
0000004e jmp 0000006D
{
double x = System.Math.Sin(val);
00000050 fld qword ptr [ebp-8]
00000053 sub esp,8
00000056 fstp qword ptr [esp]
00000059 call 65081211
0000005e fstp st(0)
00000060 nop
val += dt;
00000061 fld qword ptr [ebp-10h]
00000064 fadd qword ptr [ebp-8]
00000067 fstp qword ptr [ebp-8]
for (int i = 0; i < _iterationCount; ++i)
0000006a inc dword ptr [ebp-14h]
0000006d mov eax,dword ptr [ebp-14h]
00000070 mov edx,dword ptr [ebp-18h]
00000073 cmp eax,dword ptr [edx+0Ch]
00000076 jl 00000050
}
а реально этого не происходит
Почему заблуждение, это показывает что некторые компиляторы умеют такое оптимизировать.
Это было бы допустимо только если это был тест оптимизаторов и эта «деталь» была показана автором топика, а не найдена мной как читателем.
Чесно сказать для меня компилятор это черный ящик, как они добиваются скорости, это не моего ума дела. Если скорости добились такой оптимизацией то все ок. Я тока рад что они про это подумали.
За что спасибо вам огромное! я показывал предварительно черновик нескольким своим друзьям и знакомым (программистам, достаточно серъёзным) и никто даже не намекнул мне что там может быть такой косяк подобного рода )
Интересно почему оно вообще цикл не убрало? Старая досовская боязнь что его использует как замедление времени? :-)
Было бы интересно увидеть результаты моно под llvm.
Мне кажется, что самым правильным сравнением производительности Java, .NET и Mono было бы следующее: берётся два человека — гуру Java и гуру .NET + Mono.
Ставится общая задача: на вход подаётся, например, xml-файл с входными параметрами для ряда сложных тестов (e.g., решение СЛАУ заданным алгоритмом, сортировка массива заданным алгоритмом, сортировка списка заданным алгоритмом, etc).
На выходе должен быть файл с результатами также заданного формата.
Ну а далее в одинаковых начальных условиях многократно запускаются тесты, проводятся замеры.
Профит в том, что можно будет увидеть производительность оптимизированных под язык программ.
Ставится общая задача: на вход подаётся, например, xml-файл с входными параметрами для ряда сложных тестов (e.g., решение СЛАУ заданным алгоритмом, сортировка массива заданным алгоритмом, сортировка списка заданным алгоритмом, etc).
На выходе должен быть файл с результатами также заданного формата.
Ну а далее в одинаковых начальных условиях многократно запускаются тесты, проводятся замеры.
Профит в том, что можно будет увидеть производительность оптимизированных под язык программ.
В общем, вполне разумно. Но это скучно и объективно, мало пространства для троллинга, потому никто не будет делать такие бенчмарки, вы же понимаете?
Да, понимаю )
Настоящая цель многих и многих авторов бенчмарков, тайная, в которой они может даже себе стесняются признаться — это не ВЫЯСНИТЬ, что быстрее, а ПОДТВЕРДИТЬ свои или чьи-то предпочтения / предположения / мнения.
«Питон быстрее руби! Вы мне не верите?! Сейчас я набросаю вам бенчмарк, который вам это покажет.»
«Питон быстрее руби! Вы мне не верите?! Сейчас я набросаю вам бенчмарк, который вам это покажет.»
Я если что готов со стороны дотНет поучавствовать.
С одной стороны решение хорошее, с другой стороны все опять упирается в то, кто из Гуру больше Гуру, и насколько задача «решение СЛАУ заданным алгоритмом, сортировка массива заданным алгоритмом, сортировка списка заданным алгоритмом, etc» соответствует канонам той или иной веры.
Но было бы интересно посмотреть, у Вас нету подходящих Гуру на примете? :)
Но было бы интересно посмотреть, у Вас нету подходящих Гуру на примете? :)
Пардон, накосячил. Ответ на сообщение bazzilic.
Хорошо, что я зашел посмотреть комменты )
Нет, к сожалению нету, а сам я скорее в плюсах разбираюсь, да и то, не стал бы говорить, что я гуру.
Ну тут, кстати, будет проверяться не только сама вычислительная мощь, но и чтение/запись больших файлов, то есть тест будет более реальным, чем предложенные в статье.
Нет, к сожалению нету, а сам я скорее в плюсах разбираюсь, да и то, не стал бы говорить, что я гуру.
Ну тут, кстати, будет проверяться не только сама вычислительная мощь, но и чтение/запись больших файлов, то есть тест будет более реальным, чем предложенные в статье.
попробуем с товарищем погонять разные алгоритмы по вычислительной математике — учебный год кончился, лаб на данную тематику скопилось достаточно )
о результатах отпишемся к выходным.
о результатах отпишемся к выходным.
Тут все кричат про ключ -server. Я скачал тесты и запустил на своей машине с ключами -client и -server
Запускал только то что мне было интересно: доступ к коллекциям
Запускал только то что мне было интересно: доступ к коллекциям
.net 4.0
9,86437_op/mks_202,75_ms._2E+008_DynamicArray последовательный доступ к элементам
0,08114_op/mks_616,25_ms._5E+004_DynamicArray вставка и удаление элементов
1,34907_op/mks_741,25_ms._1E+008_LinkedList последовательный доступ к элементам
3,72648_op/mks_1341,75_ms._5E+006_LinkedList вставка и удаление элементов
51,28205_op/mks_195,00_ms._1E+007_Stack вставка и удаление элементов
9,87654_op/mks_101,25_ms._1E+006_Queue вставка и удаление элементов
2,53807_op/mks_394,00_ms._1E+006_Dictionary<int, string> вставка и удаление элементов
42,78075_op/mks_46,75_ms._2E+006_Dictionary<int, string> последовательный доступ к элементам
Java -client
1,31406_op/mks_1522,00_ms._2e+08_DynamicArray последовательный доступ к элементам
0,05938_op/mks_842,00_ms._5e+04_DynamicArray вставка и удаление элементов
0,65147_op/mks_1535,00_ms._1e+08_LinkedList последовательный доступ к элементам
4,27716_op/mks_1169,00_ms._5e+06_LinkedList вставка и удаление элементов
8,11688_op/mks_1232,00_ms._1e+07_Stack вставка и удаление элементов
2,37530_op/mks_421,00_ms._1e+06_Queue вставка и удаление элементов
3,20513_op/mks_312,00_ms._1e+06_Dictionary<int, string> вставка и удаление элементов
6,23053_op/mks_321,00_ms._2e+06_Dictionary<int, string> последовательный доступ к элементам
MaxTotalMemory: 416497112
Java -server
1,56372_op/mks_1279,00_ms._2e+08_DynamicArray последовательный доступ к элементам
0,06739_op/mks_742,00_ms._5e+04_DynamicArray вставка и удаление элементов
1,11359_op/mks_898,00_ms._1e+08_LinkedList последовательный доступ к элементам
3,52361_op/mks_1419,00_ms._5e+06_LinkedList вставка и удаление элементов
8,39631_op/mks_1191,00_ms._1e+07_Stack вставка и удаление элементов
8,06452_op/mks_124,00_ms._1e+06_Queue вставка и удаление элементов
3,14465_op/mks_318,00_ms._1e+06_Dictionary<int, string> вставка и удаление элементов
11,69591_op/mks_171,00_ms._2e+06_Dictionary<int, string> последовательный доступ к элементам
Пробовал заменить ArrayList в первых двух тестах на ArrayIntList из Apache Commons Primitives, скорость выполнения теста возрастает назначительно
Java -server
1,72861_op/mks_1157,00_ms._2e+08_DynamicArray последовательный доступ к элементам
0,06974_op/mks_717,00_ms._5e+04_DynamicArray вставка и удаление элементов
Вот как-то так.1,31406_op/mks_1522,00_ms._2e+08_DynamicArray последовательный доступ к элементам
А что это такое? Я бы хотел видеть среднее количество операций в секунду / в минуту.
А что это такое? Я бы хотел видеть среднее количество операций в секунду / в минуту.
Посмотрел исходники (смотрел только java так как и так понятно что автор хорошо владеет C# (ибо он типа рвёт всех) ) — тесты абсолютно бессмысленные, написаны коряво, да и видно что автор с java вообще незнаком.
Compare the performance of ≈24 programming languages for 4 different combinations of OS/machine < — И раз уж собрались письками меряться — уже всё давно померяли за вас :)
Compare the performance of ≈24 programming languages for 4 different combinations of OS/machine < — И раз уж собрались письками меряться — уже всё давно померяли за вас :)
Все померяли, говорите? Что-то там не видно нормального C# под виндой. Сплошная убунта.
Ну уж извените что Microsoft .NET Framework не работает под линь и под мак :)
Если уж собираетесь измерять скорость то нужно измерять кроссплатформенные варианты.
В конце концов, что вам мешает скачать все тесты и запустить под винь (в том числе и под «нормальный C#» )
Если уж собираетесь измерять скорость то нужно измерять кроссплатформенные варианты.
В конце концов, что вам мешает скачать все тесты и запустить под винь (в том числе и под «нормальный C#» )
Я уже отметил кстати выше про размер кеша процессора :)
Насчет микросекунд — да, это тоже бред еще тот. Мерить надо число операций (миллионы) в секунду, в 10 секунд, в минуту.
Насчет микросекунд — да, это тоже бред еще тот. Мерить надо число операций (миллионы) в секунду, в 10 секунд, в минуту.
Ну померяете вы свой MIPS или даже, боже упаси, MFLOPS. Во-первых — это снова упирается в вашу аппаратуру, во-вторых — в оптимизацию кода компилятором. Одна и та же программа в разное количество команд может быть преобразована, а время выполнения от этого напрямую никак не зависит. Какая разница во что преобразуется программа — важнее для меня (как для разработчика, пользователя) каково будет время работы программы.
если одна платформа генерирует код, который упирается в размер кэша, в то время как платформа конкурента генерирует нормальный код, то это — проблема платформы и такая платформа вполне заслужено получит плохой результат теста
Реквестирую включение в тест С++
По моим прикидкам, самые частые операции в среднестатистическом приложении, оставшиеся за кадром, — заполнение и поиск в словаре Dictionary или HashTable, вызов делегатов, а так же вызов виртуальных методов, выполнение итераторов (yield return). Хорошо бы сравнить производительность еще и этих операций.
Жаль что нет mono на винде, было бы интересно сравнить с CLR и mono на линухе. Я, например, не ожидал что Java будет себя практически одинаково вести на разных системах.
Хм, занимательная статья, спасибо. Жаль картинки не кликабельные.
Давно хотел почитать статью где сравниваются разные платформы на разных операционных системах. Очень полезная для того, чтобы понять, что где и когда. А то обычно все затьюнено до предела, и не понимаешь, где хорошо постарались, а где не очень. А здесь так сказать, без прикрас. Спасибо!
Работа проделана большая, статья хорошая. Но сам предмет обсуждения, как мне кажется, не стоит такого внимания, увы.
Раз пошла такая пьянка, вот еще (но там нет .NET):
days2011.scala-lang.org/sites/days2011/files/ws3-1-Hundt.pdf
days2011.scala-lang.org/sites/days2011/files/ws3-1-Hundt.pdf
ИМХО, было бы полезней померять, например, Lucene Java с Lucene .NET на большом количестве документов с разными типами операций.
Блять! Я знал! Теперь пускай мне ток кто нить скажет что .Net тормозной ублюдок! Разорву!
Автору спасибо! Такого прироста счастья я давно не испытывал! :) :)
Автору спасибо! Такого прироста счастья я давно не испытывал! :) :)
вы сходите в микрософт, оракл и вам так ещё лучше расскажут, что .NET или java быстрее)))
Замечательное подтверждение моего утверждения выше:
Настоящая цель многих и многих авторов бенчмарков, тайная, в которой они может даже себе стесняются признаться — это не ВЫЯСНИТЬ, что быстрее, а ПОДТВЕРДИТЬ свои или чьи-то предпочтения / предположения / мнения.
«Питон быстрее руби! Вы мне не верите?! Сейчас я набросаю вам бенчмарк, который вам это покажет.»
Спасибо, мне всегда приятно видеть, что мои оценки мотивации отдельных людей или групп верны :)
Настоящая цель многих и многих авторов бенчмарков, тайная, в которой они может даже себе стесняются признаться — это не ВЫЯСНИТЬ, что быстрее, а ПОДТВЕРДИТЬ свои или чьи-то предпочтения / предположения / мнения.
«Питон быстрее руби! Вы мне не верите?! Сейчас я набросаю вам бенчмарк, который вам это покажет.»
Спасибо, мне всегда приятно видеть, что мои оценки мотивации отдельных людей или групп верны :)
Да, вы безусловно специалист в мотивации отдельных людей или групп. :)
В целом, мне приятно, что технология которую я постоянно использую показывает такие результаты в одном из бенчмарков. Мне по настоящему это приятно и делает меня счастливее. :) Покажет в другом результаты хуже, станет грустнее.
Чего вы там своими оценками хотите показать мне абсолютно не понятно. Самоутвердится в том, что ваши оценки верны? Молодец, у вас все получилось. У данного бенчмарка тоже есть оценки, но они для меня более понятны чем ваши.
Про то зачем делают бенчмарки, вы правы. И даже как то странно думать что кто то может думать иначе.
В целом, мне приятно, что технология которую я постоянно использую показывает такие результаты в одном из бенчмарков. Мне по настоящему это приятно и делает меня счастливее. :) Покажет в другом результаты хуже, станет грустнее.
Чего вы там своими оценками хотите показать мне абсолютно не понятно. Самоутвердится в том, что ваши оценки верны? Молодец, у вас все получилось. У данного бенчмарка тоже есть оценки, но они для меня более понятны чем ваши.
Про то зачем делают бенчмарки, вы правы. И даже как то странно думать что кто то может думать иначе.
Да нет, я вовсе не такой тролль, каким выгляжу здесь. Просто ваш предыдущий пост был такой… ну… эмоциональный) Собственно, моя ирония была направлена как против вас, так и против тех, кто говорит вам, что ".Net тормозной ублюдок".
Да я вообще эмоциональный человек. :) И если есть повод радоваться — я радуюсь. :)
Конечно, я прекрасно понимаю что нельзя верить всему что пишут. Но… но ведь правда приятно! :)
Я понимаю вашу иронию, и не осуждаю, она, что называется, в тему. :) Но, уж извините, мне правда в кайф. :) :) И черт с ним что люди подумают. :)
Конечно, я прекрасно понимаю что нельзя верить всему что пишут. Но… но ведь правда приятно! :)
Я понимаю вашу иронию, и не осуждаю, она, что называется, в тему. :) Но, уж извините, мне правда в кайф. :) :) И черт с ним что люди подумают. :)
Жаль не результатов OpenJDK. Субъективно тормознутее, чем сановский оракловский
Кстати, ты. Надо бы прогнать еще и под JRockit, сравнить ))
В тестах от гугл используются разные GC и результаты на лицо www.opennet.ru/opennews/art.shtml?num=30784
Извините не понял. В моно тестировались сборки сделанные в MS .NET? Или Windows тесты собирались под Windows, а Mono под Linux c помощью msc?
Интересная тема, но подправь, пожалуйста оформление. Глаза немного режет оформление. Картинки перезалей, не видно ничего. Куски кода не очень интересно смотреть, спрячь их под споилер. В конце подведи итог: сделай наглядную сводную таблицу с конкретными числовыми значениями, пожалуйста.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Сравнительное тестирование производительности платформ .Net, Java и Mono