Тест производительности на Java VM против .NET CLR

Question

Вам когда-нибудь приходилось оправдывать выбор в пользу использования .NET вместо Java в зависимости от производительности?

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

• параллельных транзакций базы данных
• Математические вычисления
• Взаимодействие с другими веб-сервисами (SOAP / XML, XML-RPC)

Мой подход заключается в том, чтобы тестировать эталонные тесты в Java для JVM и C # для .NET CLR, которые сравнивают вышеуказанные операции при различных уровнях нагрузки и сравнивают результаты.

За исключением языковых и платформенных предпочтений, Мне интересно узнать, как вы будете проводить окончательное сравнение производительности между Java VM и .NET CLR?

Существуют ли какие-либо всеобъемлющие и уважаемые критерии?

Answer 1

У меня нет точных цифр эффективности JVM против CLR, но разница, если таковая имеется, скорее всего, будет небольшой.

Однако в языковой части C # имеет несколько более низкоуровневых конструкций, чем Java, что позволило бы обеспечить большую оптимизацию.

Такие конструкции, как:

• Определяемые пользователем типы значений. Быстро выделяется, не требует дополнительной памяти (что составляет 12 байт на ссылочный тип в CLR и JVM, если я правильно помню). Полезно для вещей, которые позволяют естественным образом выражать себя в виде значений, таких как векторы и матрицы. Итак, математические операции. Объедините это с ref и out, чтобы избежать чрезмерного копирования этих типов больших значений.

• Небезопасные блоки кода, которые позволяют немного больше «приблизиться к металлу» оптимизации. Например, хотя CLR и JVM могут избегать проверок границ массивов в некоторых ситуациях, во многих случаях они не могут, и каждый доступ к массиву требует проверки, находится ли индекс по-прежнему в пределах границ массива. Использование здесь небезопасного кода позволяет получать доступ к памяти массива напрямую с помощью указателей и обходить любые проверки границ. Это может означать значительную экономию. И на очень низком уровне, есть также stackalloc, который позволяет вам размещать массивы непосредственно в стеке, тогда как нормальный массив выделяется в куче, что медленнее, но также более удобно. Лично я не знаю никаких практических применений stackalloc.

• Настоящие дженерики, в отличие от типов, стирающих дженерики Java, избегают ненужных приведений и упаковок. Но если это проблема в вашей Java-программе, ее можно легко решить с помощью некоторой дополнительной работы (переключение, например, с ArrayList<Integer> на пользовательский тип, который внутренне использует буфер int[].)

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

Answer 2

окончательное сравнение производительности между Java VM и .Net CLR - несбыточная мечта. Вы всегда можете сделать тест производительности, который будет выглядеть лучше, чем другой, так как разработка сложной системы всегда требует компромиссов. Если вы сузите тип эталонных тестов до скорости выполнения и памяти, вы можете найти такие статьи: http://www.codeproject.com/KB/dotnet/RuntimePerformance.aspx это ни в коем случае не конец дискуссии.

Answer 3

За исключением языковых и платформенных предпочтений, мне интересно услышать, как вы будете проводить окончательное сравнение производительности между Java VM и .Net CLR?

Я бы написал набор тестов, предназначенных для сравнения различных характеристик двух виртуальных машин и их стандартных библиотек. Мой опыт в технических вычислениях, поэтому я бы порекомендовал следующее:

• В регистре целочисленная арифметика, например, Фибоначчи.
• В регистровой арифметике с плавающей запятой, например Мандельброт.
• Итерация массива, например FFT.
• Распределение, например чисто функциональные красно-черные деревья.
• Хеш-таблицы с клавишами и значениями типа int или float.
• Хеш-таблицы со строковыми ключами и значениями.
• Строки.
• Регулярные выражения.
• File IO.

Возможно, вы можете придумать что-то похожее для баз данных и веб-сервисов.

Не забывайте, что языки, расположенные поверх CLR, имеют совершенно разные свойства. Например, inline в языке F # позволяет автоматизировать оптимизацию, которая может дать огромный прирост производительности по сравнению с C #. И наоборот, goto в C # позволяет вам делать некоторые вещи более эффективно, чем это возможно в F #, а оптимизация структур была более эффективной в C #, чем F # (последнее, что я смотрел).

Существуют ли какие-либо всеобъемлющие и уважаемые критерии?

Нет, но есть много разрозненных ориентиров, которые фокусируются на выбросах, потому что они более интересны. Например, это сообщение в блоге описывает, почему простой эталонный тест хеш-таблицы может быть в 17 раз быстрее в F # в .NET, чем в Java в JVM. В этом случае причина была в том, что типы значений и усовершенствованные обобщенные элементы позволяют писать гораздо более эффективную реализацию универсальных хеш-таблиц в .NET, чем в JVM.

Answer 4

Я также подумал, что даст лучшую производительность. Но понятия не имею о том, как я могу выполнить тест для этого.

Итак, хороший вопрос - надеюсь, мы все получим некоторые указания здесь.

Я полагаю, что это тестирование должно быть «тестовым» подходом со скидкой (его легко настроить и запустить 1 разработчик)?

У меня есть такая информация, это было бы здорово. Меня часто просят оценить технологии самостоятельно в короткие сроки.

Отличный bunn_online!

Answer 5

Тесты ... Вы можете проверить почти все с помощью теста, который соответствует вашим потребностям.
За исключением Чака Норриса. Чак Норрис медленнее и быстрее Х, если он того пожелает.

Еще один момент. Допустим, вы пришли к выводу, что Java быстрее. Означает ли это, что через 2 года все еще будет быстрее?

Если Java на 5% быстрее, а .NET на 10% проще, с чем бы вы поработали?
Есть много факторов, и производительность - только один из них. И если различия невелики (я думаю, что они есть), это, вероятно, не самый важный.

Если вы не создаете что-то, что очень критично для производительности.

Answer 6

К вашему сведению, вам определенно не разрешено использовать код .NET Framework для любых форм сравнительного анализа без предварительного обращения к Microsoft и получения их разрешения.

Если бы вы захотели опубликовать что-то, я подумала, что сообщу вам.

Из памяти MS создала несколько книжных магазинов, которые сначала сделала Java, чтобы показать, как их программное обеспечение может работать более эффективно при выполнении той же задачи. Я пытаюсь думать об этом.

.NET Pet Store

Answer 7

Да, есть тестовая игра, она довольно всеобъемлющая и позволяет сравнивать множество разных вещей.

http://shootout.alioth.debian.org/

Единственное, что он использует моно вместо визуальной студии, но разница в производительности между ними теперь очень мала.

в общем случае java обычно немного быстрее (в зависимости от того, что вы делаете), но использует гораздо больший объем памяти, и оба имеют примерно одинаковый размер источника.