Немного посидев за симметричными микробенчмарками на Java и .Net, пришел к выводу, что .Net тормознее Java на вычислительных задачах процентов на 30% примерно.
Ну то есть берем один и тот же алгоритм, пишем равнозначный эффективный код на обеих платформах (с учетом специфики, разумеется). Потом профилируем по отдельности, что бы убедиться, что нету никаких косяков с точки зрения перформанса.
А потом сравниваем полученные цифры, и видим, что .Net стабильно прямо ощутимо тормознее Java.
Я не смог найти в интернете исследований на эту тему. Разве что, у разных уважаемых людей из мира перфоманса, постоянно между строк сквозит, что в .Net очень простенький и слабенький JIT. В принципе, других причин для тормозов я и не вижу, кроме него: не могут в Microsoft написать такой же умный компилятор, как в Oracle.
Кто-нибудь может поделиться сслыками с научными изысканиями на эту тему, или с глубоким анализом и/или сравнением компиляторов в Java и .Net?

Arm79 http://habrahabr.ru/post/120090/

ну и в Wiki в разделе references есть ссылки на сравнение производительностиГовно. Можно даже не смотреть. Когда человек в качестве бенчмарка выдает вот такое:

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

Отбрасываем, нужны еще ссылки.

Arm79во-вторых, указанный код автор позиционирует как скорость выдачи псевдослучайных значений, оговариваясь именно скоростью, а не качеством данных или еще чем. Там что, хоть и не очень важный параметр, но как второстепенный критерий вполне пойдет.Вы не поняли. Проблема не в том, что у него что-то не то сравнивается. Проблема в том, что он неправильно пишет бенчмарки. Когда вы присваиваете результат чего-либо локальной переменной, которая потом нигде не используется, компилятор может вообще выпилить этот код вместе с циклом, если докажет, что данный код не имеет сторонних эффектов, оставив вас с чем-то вроде:

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

Arm79Свеном, опять вам все не так. В Wiki тоже все плохо?Комплексного анализа там нигде нет.

ВМоисеев ,
Ну хз насколько там грамотные люди все это писали. Короче, все более менее ясно - Java быстрее. Почему она быстрее тоже понятно - гораздо более крутой компилятор. CLR опирается на compile-time информацию, и практически беспопощен в рантайме. Java же наоборот отжигает в рантайме, и на всевозможных спекуляциях рвет .Net в клочья.

Почитал, все не то.
Натив - шляпа, никакого прироста на серверных приложениях не даст, так как там итак весь горячий код давным давно скомпилирован в натив.
РиуДжит - шляпа, так как уучшают время компиляции в первую очередь, а по динамической компиляции ничего не предвидется.

В общем, это все печеньки для окошечек и мобильных приложений. Я же спрашивал про сервер-сайд. Здесь .Нет по-прежнему ничего хорошего не светит.

ВМоисеев>cdtyjv, сегодня, 12:55 [16633576]
>... рвет .Net в клочья .

Не доказано.
Здесь (16 фев 08, 13:26 [5299013] ) попытался сравнить.
Результат - это не тузик и грелка.
Надо иметь тест-программу и запускать её варианты (Net & Java) на одной и той же машине. И аккуратней с проверкой границ массива - проверка включена/выключена.

С уважением,
Владимир.Попытаться то он попытался, но бенчмарк у него некорректный, так что его цифрами можно разве что ... ну вы понели.

ВМоисеев ,
Я не могу выкладывать проприетарный код. Что до ваших бенчмарков, то вам надо было сначала хотя бы прогреть JVM-ку, и убедиться, что компиляция завершилась. После этого хорошо бы взглянуть на сгенерированный ассемблерный код, что бы убедиться, что вы действительно меряете именно то, что хотите: что не сработал dead code elimination, что циклы либо одинаково на месте, либо одинаково раскрутились на обеих платформах, и т.д..
А то это все от лукавого - сравнение непонятно чего с непонятно чем.