LINUX.ORG.RU

Java SE 6 Performance White Paper


0

0

Представлен сравнительный обзор показателей производительности и улучшений в масштабируемости Java стандартной версии 6 (Update 2) в сравнении с предыдущей версией платформы Java 5.0.

Java SE 6 включает несколько новых функций и усовершенствований для повышения производительности во многих частях платформы. Улучшения включают:

  • синхронизованные оптимизации выполнения, оптимизации производительности компилятора;
  • новый параллельный уплотняющий сборщик мусора (Parallel Compaction Collector);
  • более эргономичный параллельный низколатентный сборщик мусора (Concurrent Low Pause Collector);
  • ускорение запуска приложений.
Сравнение современной версии Java SE 6 Update 2 ведётся с предыдущей версией платформы -- Java SE 5 FCS.
Так, например, производительность операций ввода-вывода Java 6 в два раза выше, чем у Java 5.0; производительность корпоративных систем по тесту SPECjbb2005 Benchmark возросла на 70%; производительность Java в популярном тесте VolanoMark Benchmark выросла более чем на 40%; скорость запуска приложений увеличилась на 15-20%.

Также приводятся ссылки на материалы, посвящённые отдельным оптимизациям и тестам. В частности, интерес представляет отимизация сборки мусора и уменьшения потребления памяти в отдельной статье "Java SE 6 HotSpot[tm] Virtual Machine Garbage Collection Tuning":
http://java.sun.com/javase/technologi...

Другие ссылки приведены по ходу обзора и в его конце.

>>> Подробности

Ответ на: комментарий от anonymous

>anonymous (*) (18.11.2007 15:54:28) >А в качестве маленького бонуса - полная кроссплатформенность

Я плакаль :) проста ппц. Велика сила веры, разум отдыхает ...

anonymous
()
Ответ на: комментарий от anonymous

Здравствуйте!

Я немножко начинающий в Линуксе, но хотел бы посоветоваться с гуру сайта linux.org.ru. Я программирую на Java (5 версия) но есть одна проблема- мои программы запускаются и работают без тормозов. Скажите, может я что-то не так делаю? Просто некоторые сообщения меня немножко волнуют - вполне возможно мне еще стоит научиться по-другому писать программы чтобы все работало "как надо"? Мне приходится создавать программы на заказ, поэтому для меня это очень важно.

У меня Athlon 1000 Mhz, 512 RAM, AC 97 встроенная

Спасибо вам огромное за сайт!

anonymous
()
Ответ на: комментарий от xTERM

>Во-во. Почему нельзя один раз при инсталляции скомпилировать все свои библиотеки классов? Почему нельзя сохранить скомпилированную из байткода программу? Когда наконец это все будет??? Даже в Parrot это возможно!

Частично это для стандартных библиотек сейчас делается (поэтому бэты JDK6 Update 5 при запуске просто летают). Полностью оно принципиально невозможно, так как HotSpot использует спекулятивную компиляцию.

Т.е. он выбрасывает виртуальные вызовы, если есть только одна реализация, делает инлайнинг и т.п.

В теории, можно было бы использовать "грубую" JIT-компиляцию приложений для ускорения запуска. Но на практике, это помогает только для стандартных библиотек.

anonymous
()
Ответ на: комментарий от anonymous

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

Замените Tomcat на Jetty, в настройках JVM поставьте -client-версию, поставьте JRE поновее. И телемаркет - будет занимать в памяти около 100Мб и запускаться примерно за 4 секунды.

anonymous
()
Ответ на: комментарий от anonymous

За что я люблю ЛОР так это за отменное чувство юмора у ананимусоф и результирующий срач в каментах.
ЗЫ. Сам Вендузятник, прихожу сюда чисто поржать :D

anonymous
()
Ответ на: комментарий от ilnurathome

> Ничего не поставит. пользователь по прежнему будет запускать class/jar а кэш хранится в /var/cache/java/precompiled

Уже кучу раз писалось. Такой подход - реальная дыра в безопасности. Почему? Почитай, хотя бы. топик про LD_PRELOAD_PATH

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

> Т.е. если бы работало по аналогии с man
man не исполняет, а отображает данные из кеша. Разница понятна?

Korwin ★★★
()
Ответ на: комментарий от anonymous

+1

Классный троллинг! Кульхакцкеры питонщики + МЛщики + рубильники + пыхеры могут нервно курить в сторонке.

Bioreactor ★★★★★
()
Ответ на: комментарий от anonymous

> а может быть mysql спрятали специально за J2EE, иначе пришлось бы навешивать на продукт сторонний антивирус/файерволл?

Нет.

anonymous
()
Ответ на: комментарий от anonymous

Нет, это не так.

Но, действительно, почему то у меня очень быстро тоже Джава под Fedora (у меня, правда, Java 6 - новые классы коллекций таки нужены) работает. Я сам не могу понять почему у меня все работает.

Bioreactor ★★★★★
()
Ответ на: комментарий от Korwin

> Уже кучу раз писалось. Такой подход - реальная дыра в безопасности. Почему? Почитай, хотя бы. топик про LD_PRELOAD_PATH
1. Нет ты че загoняешься, тебе что предлагают elf бинарес делать, для этого есть нативные java компиляторы
2. целостность файлов в должна обеспечивать система, в частности selinux
3. Кто помешает проге прописать в ~/.bashrc скрипт в котором используется LD_PRELOAD_PATH на вредоносный код под ~/sysfuck и как это повлияет на систему в целом. (Без использования java.)
4. некуй под рутом работать и запускать от его имени критические сервисы
5. в /var/cache/jvm/ кидать только либы из jdk/jre и проги установленные в /usr/bin etc, а в ~/tmp/jvm_cache пользовательские проги если ему разрешено их пускать
6. если имеется в виду топик про
http://www.linux.org.ru/view-message.jsp?msgid=2276232
то не LD_PRELOAD_PATH, а LD_LIBRARY_PATH

ilnurathome
()
Ответ на: комментарий от anonymous

> ведь JBoss Portal требует 512Мб памяти

JBoss Portal требует 512 метров виртуальной памяти и только 128 метров RSS. Причем это можно настроить и зарезать в run.conf.

Aceler ★★★★★
()
Ответ на: комментарий от ilnurathome

> ну как запустишь под ним чет более менее реальное, отпостишься.

А вот реального я там запускать не буду :) Wiki + Rss ретранслятор + ftp + CMS.

Aceler ★★★★★
()
Ответ на: комментарий от Aceler

> Ты уж определись, тебе в продакшне использовать или бету. :)

Да я уже определился, желательно не использовать вообще. :)

Bohtvaroh ★★★★
()
Ответ на: комментарий от anonymous

Хоть фраза адресовалась и не мне, рискну ответить.

>А время на JIT компиляцию ты учел? Может он все это время перегонял байт код в инструкции проца?

Так на кой ляд мне это шило надо, если приложение уже установлено? На кой ляд гонять компиляцию при _каждом_ запуске? Греем окружающее пространство, близим тепловую смерть вселенной?

Вообще, меня давно интересовал вопрос: если уж делаете свой убер-переносимый байт-код, почему бы не компилить его до машинных инструкций в момент _инсталляции_, а не запуска? Повторюсь: на кой ляд при каждом запуске делать recompile?... Или вы каждый новый запуск выполняете на новом железе?...

Sectoid ★★★★★
()
Ответ на: комментарий от anonymous

>>для длительный операций принято делать отдельный поток и показывать в гуйке синего червяка. если это не сделано _мгновенно_(1/25 секунды), то программа тормозит.

> То есть когда ты в Vim|Emacs|VisualStudio нажимаешь "Run", у тебя среда компилирует проект и запускает его менее чем за 1/25секунды? Круто. Ничего что у меня в Eclipse я жду немножко дольше?

среда(я обычно юзаю kdevelop) мне _мгновенно_ начинает показывать логи компиляции, а не подвисает как эклипс на пару секунд.

> А, кстати, когда ты нажимаешь "Поместить" на странице http://www.linux.org.ru/view-message.jsp?msgid=2278155 понимаешь ли ты, что тормозит не сама Java, которая обрабатывает твое нажатие, а твое сообщение еще успевает поместиться в базу и уже потом Java отдает тебе страницу с твоим ответом?

здесь я вижу, что тормозит веб-интерфейс.

gaa ★★
()
Ответ на: комментарий от dave

>>> ещё раз повторю: "дорогой" форк - это инвариант любого не-нативного языка. не важно, что потом будет тормозить или не тормозить исполнение, форк от этого не подешевет.

> Не совсем понял смысл написанного. Тут все так относительно... Уже не всегда разберешь, где натив, а где виртуалка.

смысл: затраты на запуск есть при любом способе запуска кроме запуска нативной программы. да и то динамическую линковку можно посчитать за интерпретируемость :)

разделить легко: если для разных архитектур процессора/системы используется один и тот же код - то это "виртуалка"

>> да. но не всякий язык(в отличие от жавы) тянут во _все_ типы задач.

> Но у меня нет такого ощущения, по крайней мере, ядро Solaris никто еще не вздумал переписать на Java. Или, может быть, я что-то пропустил? :)

цитирую санок: http://www.sun.com/software/learnabout/java/

The Java platform is the ideal platform for network computing. Running across all platforms -- from servers to cell phones to smart cards -- Java technology unifies business infrastructure to create a seamless, secure, networked platform for your business.

т.е. они активно пихают жаву во все дыры(сильнее санок это делает только мс с аналогичным продуктом), хоть сами уже косвенно признали, что ничего в ней интересного кроме j2ee нет, отдав все остальные ипостаси жавы в опенсорс.

gaa ★★
()
Ответ на: комментарий от Aceler

> Кричащие Java - тормоз идут покупать мне новый процессор.

хотите чтобы мы платили за Ваш просчёт в используемой технологии? да Вы, батенька, в сановские манагеры метите :)

gaa ★★
()
Ответ на: комментарий от anonymous

> это такой тонкий тролль

главное - не кормить, а то отожрётся на лоровских харчах ;)

gaa ★★
()
Ответ на: комментарий от Korwin

>> Ничего не поставит. пользователь по прежнему будет запускать class/jar а кэш хранится в /var/cache/java/precompiled

> Уже кучу раз писалось. Такой подход - реальная дыра в безопасности. Почему? Почитай, хотя бы. топик про LD_PRELOAD_PATH

давайте ещё баш будет проверять каждый запускаемый им бинарник, вдруг там тоже какая-нибудь кака окажется?

не надо делать из JVM Ос в ОС. пусть жава исполняет бинарники, а системными делами пусть займётся система.

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

зачем проверять crc у закешированного бинарника? пусть поддержанием целостности занимается фс. или у Вас FAT?

> Т.е. если бы работало по аналогии с man man не исполняет, а отображает данные из кеша. Разница понятна?

нет.

gaa ★★
()

Сегодня после прочитанной статьи решил поменять jvm c версии 1.6_1 до 1.6_3 - результат на лицо. Мой Эклипс стал загружаться в 2 раза быстрее. У меня стоит ubuntu 7.10. На Винде не тестировал

anonymous
()
Ответ на: комментарий от anonymous

> Я программирую на Java (5 версия) но есть одна проблема- мои программы запускаются и работают без тормозов. Скажите, может я что-то не так делаю?

Уезжай из Эстонннннии

anonymous
()
Ответ на: комментарий от gaa

>>> ещё раз повторю: "дорогой" форк - это инвариант любого не-нативного языка. не важно, что потом будет тормозить или не тормозить исполнение, форк от этого не подешевет.

> Не совсем понял смысл написанного. Тут все так относительно... Уже не всегда разберешь, где натив, а где виртуалка.

смысл: затраты на запуск есть при любом способе запуска кроме запуска нативной программы. да и то динамическую линковку можно посчитать за интерпретируемость :)

дополню:

Так чем же мне так не нравится дорогой форк?

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

Всё было хорошо, программка работала достаточно шустро, пока с нахдывом оптимизаторской активности мы её не переписали. Даже не на C, а на Tcl. В итоге мы сэкономили 20% времени рабочего цикла нашей программы!

А учитывая, что UNIX way - это как раз набор маленьких подпрограмм, связанных пайпами, то получается, что на java написать юниксвейную программу сложно.

Вывод: место java-ы - выделенные сервера баз данных с веб-мордой:

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

2. сетевое взаимодействие тоже не быстро

3. менеджер памяти в языках с "мусорщиками" эффективен в случае сферической VM в вакууме, т.е. если процесс этого языка - единственный и никто с ним за память не борется. Пример, почему при двух или более жручих до памяти процессах с мусорщиками система будет дестоко свопиться, я приводил тут: http://www.linux.org.ru/jump-message.jsp?msgid=2251759&cid=2253260

gaa ★★
()
Ответ на: комментарий от gaa

s/нахдывом/нахлывом/ :)

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

gaa ★★
()
Ответ на: комментарий от iZEN

> Уже пробегала новость про внутриядерную JVM и драйвер на Java в Solaris. :)

А в этой идее что-то есть! :)

dave ★★★★★
()
Ответ на: комментарий от gaa

> затраты на запуск есть при любом способе запуска кроме запуска нативной программы. да и то динамическую линковку можно посчитать за интерпретируемость :)

Но затраты на запуск обычно несопоставимы с затратами на исполнение. Вот - в чем вопрос.

Но так не всегда. Как я понял, вы каждый раз вызывали к жизни JVM на очень непродолжительное время. То есть, JVM стартовала около сотни раз за сеанс работы. Циклически выполняло простенькую работу и завершалось. Так?

Если да, то оформление Java кода как Corba-сервера, постоянно висящего в памяти, было бы более лучшим решением. Или же все приложение должно было бы быть на Java, вызывающим некоторые куски на C. Это если бы очень хотелось сделать именно на Java.

А маленькие утилиты писать на Java - не совсем правильно. Здесь согласен.

Что касается GC. Есть задачи, где он нужен. В случае C его приходится изобретать самому. В случае Java он предоставлен самой средой. Во многих таких случаях (не real-time) второе решение предпочтительнее.

dave ★★★★★
()
Ответ на: комментарий от dave

>> затраты на запуск есть при любом способе запуска кроме запуска нативной программы. да и то динамическую линковку можно посчитать за интерпретируемость :)

> Но затраты на запуск обычно несопоставимы с затратами на исполнение. Вот - в чем вопрос.

Зависит от задачи. См. исходники uname или date.

> Но так не всегда. Как я понял, вы каждый раз вызывали к жизни JVM на очень непродолжительное время. То есть, JVM стартовала около сотни раз за сеанс работы. Циклически выполняло простенькую работу и завершалось. Так?

Да. Использование java было заметным просчётом.

> Если да, то оформление Java кода как Corba-сервера, постоянно висящего в памяти, было бы более лучшим решением. Или же все приложение должно было бы быть на Java, вызывающим некоторые куски на C. Это если бы очень хотелось сделать именно на Java.

Кошмар. Совершенно не применимо к нашему продукту, в котором на java была только второстепенная утилита.

> А маленькие утилиты писать на Java - не совсем правильно. Здесь согласен.

> Что касается GC. Есть задачи, где он нужен. В случае C его приходится изобретать самому. В случае Java он предоставлен самой средой. Во многих таких случаях (не real-time) второе решение предпочтительнее.

Да это всё ясно. Только вот если уж взялся использовать gc в огромных масштабах, то приходится давать приложению отдельный сервер :(

gaa ★★
()
Ответ на: комментарий от gaa

> Только вот если уж взялся использовать gc в огромных масштабах, то приходится давать приложению отдельный сервер :(

Необязательно сервер. Это может быть клиентское приложение. См. IDE уровня IDEA, NetBeans или Eclipse. Более того, многие части оффтопичного VS также написаны на .NET. По-крайней мере, интерфейс для компонентов - дотнетовский.

dave ★★★★★
()
Ответ на: комментарий от dave

>> Только вот если уж взялся использовать gc в огромных масштабах, то приходится давать приложению отдельный сервер :(

> Необязательно сервер. Это может быть клиентское приложение. См. IDE уровня IDEA, NetBeans или Eclipse.

Выделенный сервер -- компьютер, на котором запущено _одно_ java_приложение. Потому что если их два(например, eclipse и jboss, с которыми я в текущий момент имею дело), то начинается игра "вгони противника в своп".

> Более того, многие части оффтопичного VS также написаны на .NET. По-крайней мере, интерфейс для компонентов - дотнетовский.

Ну и? Не понял, к чему это

gaa ★★
()
Ответ на: комментарий от gaa

> хотите чтобы мы платили за Ваш просчёт в используемой технологии?

Нет, за Ваши (ну не ваши, а анонимусов) утверждения, что Java тормозит.

> да Вы, батенька, в сановские манагеры метите :)

Нет уж, мы лучше сами сделаем еще лучше :D

Aceler ★★★★★
()
Ответ на: комментарий от Aceler

>> да Вы, батенька, в сановские манагеры метите :)

> Нет уж, мы лучше сами сделаем еще лучше :D

с блекджеком и шлюхами? ;)

gaa ★★
()

Мдам... Kак теперь жить местным красноглазым, кричавшим, что Java производительнее некуда?

ps
Сам работаю с Java
pps
А так-же с .Net, Perl, etc.

NonHuman ★★★
()
Ответ на: комментарий от gaa

> давайте ещё баш будет проверять каждый запускаемый им бинарник, вдруг там тоже какая-нибудь кака окажется?

А почему бы и нет?

> зачем проверять crc у закешированного бинарника? пусть поддержанием целостности занимается фс. или у Вас FAT?

Java работает на разных платформах. В том числе и на FAT. Поэтому целострость ФС в общем случае не может гарантировать.

Korwin ★★★
()
Ответ на: комментарий от gaa

> Потому что если их два(например, eclipse и jboss, с которыми я в текущий момент имею дело), то начинается игра "вгони противника в своп".

Значит, есть в каком направлении развиваться. Ограничений, накладываемых самой JVM, здесь не вижу. Несколько JVM вполне могут кооперироваться.

Также могу судить на оффтопику. Во время разработки часто проводил стресс-испытания, ну и, вообще, проверить, нет ли утечек памяти. В зависимости от размера занятой памяти GC вел себя по-разному. Если запускалось дополнительно жрущее память приложение, такое как Opera, то GC начинал вести себя заметно агрессивнее и чаще освобождал память. Вывод - все в руках разработчиков GC.

dave ★★★★★
()
Ответ на: комментарий от Korwin

> Java работает на разных платформах. В том числе и на FAT. Поэтому целострость ФС в общем случае не может гарантировать.
А вы не думали над тем под фат, что можно подменить подменить и либы в каталоге с jdk/jre, там хватает чего поменять
и вообще подменить java.exe файл на типа "format c:"

Проблемы пользователей фат не есть наша забота. Юзаешь фат под систему ССЗБ.

ilnurathome
()
Ответ на: комментарий от gaa

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

> Всё было хорошо, программка работала достаточно шустро, пока с нахдывом оптимизаторской активности мы её не переписали. Даже не на C, а на Tcl. В итоге мы сэкономили 20% времени рабочего цикла нашей программы!

>gaa (*) (19.11.2007 14:45:17)

Это ошибка в проектировании. Java предназначена для тех ситуаций, когда запускает раз и работает долго или очень долго. Unix-way на Java пишется немного по другому. В отдельных класслоадерах грузятся нужные классы, из них создаются объекты, после отработки - ссылки на объекты и класслоадеры прибиываются. Вуаля, получаем быстрое решение.

anonymous
()
Ответ на: комментарий от anonymous

>Это ошибка в проектировании. Java предназначена для тех ситуаций, когда запускает раз и работает долго или очень долго. Unix-way на Java пишется немного по другому. В отдельных класслоадерах грузятся нужные классы, из них создаются объекты, после отработки - ссылки на объекты и класслоадеры прибиываются. Вуаля, получаем быстрое решение.

Либо решение номер два. Смотрим в примере в JDK, как грузить явовскую машину. Загрузили ее из C разок и время от времени вызываем ее методы/работаем с Java данными.

anonymous
()
Ответ на: комментарий от Korwin

>> давайте ещё баш будет проверять каждый запускаемый им бинарник, вдруг там тоже какая-нибудь кака окажется?

> А почему бы и нет?

Тут недавно была в новостях статья про "ограничение доступа к linux". Там было написано про программу, проверяющую подпись любого исполняемого файла при его запуске. Советую заметить, что она была привязана ко всей системе, а не к отдельной VM.

>> зачем проверять crc у закешированного бинарника? пусть поддержанием целостности занимается фс. или у Вас FAT?

> Java работает на разных платформах. В том числе и на FAT. Поэтому целострость ФС в общем случае не может гарантировать.

FAT - платформа? Вау!

Повторяю: не надо тащить в JVM базовые функции операционной системы. А поддерживать совместимость с ненадёжной ФС под управлением ненадёжной ОС, лишь бы на ней ничего не навернулось - это вроде называется "костылём".

gaa ★★
()
Ответ на: комментарий от dave

>> Потому что если их два(например, eclipse и jboss, с которыми я в текущий момент имею дело), то начинается игра "вгони противника в своп".

> Значит, есть в каком направлении развиваться.

А если мне нужна быстрая технология _сегодня_, а не теоретическая возможность, что когда-нибудь её ускорят? Выход один: использовать другую технологию ;)

> Ограничений, накладываемых самой JVM, здесь не вижу. Несколько JVM вполне могут кооперироваться.

Отлично, покажу ограничение(кстати, надо было Вам сходить по ссылке, я его уже описал):

"Вопрос такой: а память, зажранная каждым java-процессом для ОС как выглядит? Как занятая. Хотя в большинстве случаев из-за сборщика мусора и прочих прибамбасов управляемой памяти реально используется не более половины её. Но системе об этом жабка сказать не может, потому при большом количестве таких приложений(именно потому я и говорил про единственный процесс в системе), система будет свопиться, и в своп могут попасть в т.ч. и используемые данные а не только неиспользуемая, но не неосвобождённая требуха. Вот это мне не нравится."

> Если запускалось дополнительно жрущее память приложение, такое как Opera, то GC начинал вести себя заметно агрессивнее и чаще освобождал память. Вывод - все в руках разработчиков GC.

_Как_ мусорщик узнавал о том, что запустилось прожорливое приложение? Не может он этого прямым безкостыльным способом узнать. (анализ вывода /usr/bin/free я считаю костыльным методом, т.к. он не определяет факта наличия "прожорливого" процесса)

gaa ★★
()
Ответ на: комментарий от anonymous

> Unix-way на Java пишется немного по другому. В отдельных класслоадерах грузятся нужные классы, из них создаются объекты, после отработки - ссылки на объекты и класслоадеры прибиываются. Вуаля, получаем быстрое решение.

Это _не_ unix way, т.к. всё ограничено JVM и из внешнего скрипта это так же легко как и grep не заюзаешь.

> Либо решение номер два. Смотрим в примере в JDK, как грузить явовскую машину. Загрузили ее из C разок и время от времени вызываем ее методы/работаем с Java данными.

Это неудобно, т.к. к java-программе добавляется какая-то интерактивность, что влечёт кучу дополнительного кода и test cases.

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

gaa ★★
()
Ответ на: комментарий от tailgunner

>В таких задачах работает в основном "родной" код СУБД и сетевого стека, разве нет?

Нет просто СУБД - боттлнек. Очень давно уже производительность JEE серверов упирается в производительность DBMS. Потому на серверах в энтерпрайзе жаба и доминирует - все равно быстрый мускуль будет тормозить так что никакая жаба не страшна.

r ★★★★★
()
Ответ на: комментарий от r

>>В таких задачах работает в основном "родной" код СУБД и сетевого стека, разве нет?

> Нет просто СУБД - боттлнек. Очень давно уже производительность JEE серверов упирается в производительность DBMS.

Ты сказал то же самое, но другими словами :D

tailgunner ★★★★★
()

Реальные тесты!

Вот почитал и решил бросить свои 5 копеек :)

http://www.stefankrause.net/wp/?p=6

Для тех, кто не любит (не умеет) читать ссылки:

JET 6 beta 2 is an impressive piece of software. Besides reducing startup time it has an impressive performance beating JDK 6 and 7 server in three of four benchmarks (and being very, very close in the fourth). JET 6 beta 2 is a significant improvement over JET 5. In contrast to GCJ JET is fully compatible with JDK 5 and has passed the JCK tests. The only downside is that it’s commercial and comes at a price that renders it for hobby developers unattractive.

GCJ does very well in those benchmarks and appears to be comparable with GCC performance as long as you’re willing to abandon array store checks and bounds checking. With the checks enabled GCJ can’t match the performance of current VMs.

Harmony still has a long way to go. Of course it’s still in the early stages and we’ll see performance increasing (Sun’s hotspot also took ages to become that fast), but as for today I wouldn’t use it. But I promise to rerun the benchmarks with newer builds and I’m looking forward to witnessing large performance improvements

dimag
()
Ответ на: Реальные тесты! от dimag

It’s hard to draw a conclusion because the results don’t speak just one language. But a few things can be said without regretting:

* ICC is faster than GCC in every benchmark. This is not really new information and will surprise almost no one I guess. * Judging from the worst case performance ICC is also the “safest” choice. In its slowest benchmark it was 1.6% behind the fastest contender. * Things are not as clear in the java world, but let’s try a ranking: Bea’s weakest point is the NBody benchmark where it’s 22% percent slower than the fastest JDK. Overall fannkuch was the weakest benchmark with a lag of 30% in comparison to ICC. In all other benchmarks it performed better than SUN’s or IBM’s JDKs. The lead in fannkuch to the other JVMs is impressive, so I’d call JRockit the fastest JVM for those benchmarks. * The early JDK 7 build 20 is a step in the right direction. It’s performance is better than JDK 6 in every(!) benchmark, even by 26% for NBody and 14% for fannkuch. * Saying that C is generally several times faster than java is - according to those benchmarks - simply wrong. If you’re allowed to choose the fastest JVM the worst case for java was 30%. In other benchmarks Sun and JRockit were even able to beat ICC. Not by much but I guess it’s nevertheless just very remarkable that it’s possible to beat ICC. Another interesting figure is that Bea was less than 14% slower than GCC in the worst case (nbody) and was in two cases faster than GCC. * Saying that Java is faster than C can also be pretty wrong, especially if you have to stick with one JVM. The worst case in these benchmarks were 30% slower for JRockit to 2.44 times slower for Sun’s JDK 6U2.

dimag
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.