Статья в журнале LinuxWorld «Improving Swing Performance»

Ну вот, еще один набор результатов. В позавчерашней статье на большинстве тестов был быстрее всего IBM JDK, а в этой сановский быстрее чем IBM. И обе статьи показывают JRockit тормозом.

Мое же приложение работает быстрее всего на JRockIt. Клиент, во всяком случае, сервер, из-за некоторых особенностей, ни на чем, кроме сановского jdk, не запустить. Таким образом, выходит, что существует тест, который расставит jdk в любом порядке.

Если еще кому не лень, погоняйте Excelsior, а? А то не верится этим результатам.

А вообще, получается, что нужно новый набор тестов писать, который точно определит, какой jdk на каких задачах быстрее.

От придурки! ЗАМАНАЛИ! Причем тут скорость? Вот жрал бы поменьше а так ...

Тесты тестам рознь, потому и результаты разные...

а я пишу на Pure Java и тестирую только на SUN jdk 1.4.2 и не парюсь.
потому,что апликации стоят по всему офису и бегать везде ставить ту jre, которая быстрее мне не прёт.
Я за Pure Java от Sun.

Dyk oni vse "pure" esli na Swing... Vot esli by SUN excelsioru licenciyu na kompilyaciyu Swing'a dali, chto b v .exe kompilit'... A tak smysl v chem??? Kompilit' a potom vmeste s JRE distribit'??? (Znayu ya pro SWT, ne pret).

Swing и так работает очень шустро. Все эти нативные компиляторы пишутся, видимо, от безделья. И большой скорости не прибавляют. Лично сам компилировал (год назад) Excelsior'ом SwingSet2. Cкажу чесно: то, что получилось, работало чуть-чуть медленнее, чем нормальная hot-spot машина ,и потребляло раза в полтора больше памяти. Делаю такой вывод: Excelsior разрабатывается новосибирскими студентами, и кто-то просто решил сделать из inhouse поделки коммерческий продукт. Этот же кто-то упорно муссирует слухи, что hot-spot медленный. Неправда это, hot-spot очень быстый; достаточно быстрый, чтобы вообще не замечать никаких тормозов.

Естественно... посмотрел кто автор статьи. Это Vitaly Mikheev vmikheev@excelsior-usa.com. Что он ещё мог написать? Что Jet ничем не лучше, чем hot-spot? И вообще у этого У Excelsior нет даже сертификации от Sun. Вопрос: какой нормальный человек будет использовать JVM, которая нестандартная и даже не имеет нормальных расширений (например, её даже нельзя профилировать)?

>Swing и так работает очень шустро.

Шустро но не быстро:) Хотя честно говоря скорости хватает во всяком случае мне. А с тем что нативные компиляторы это пока баловство наверное соглашусь,выигрышь по скорости не большой зато памяти жрёт заметно больше.

>Swing и так работает очень шустро.

Хм, ну так ты этот JET проверял год назад. Попробуй свежей версией.
По идее, прирост скорости должен быть. Native compilation все ж таки.

Я тоже проверял JET год назад под Windows и Linux. Мой личный вывод был: JET работал быстрее на демке SwingSet2, чем J2SE 1.4. К тому же на машине было ОЗУ 512Мб, так что напрягов с памятью не заметил.

Вообще, ребята из Новоссибирска - молодцы. Далеко не каждый из нас может похвастаться чем-то сделанным самими такого же высокого уровня. Удачи этой команде!

Если кому интересно, можете попробовать сравнить работу GCJ и JET - они относятся к одному классу, если верить статье. Так вот, если GCJ-компиленная программа не упадет в "segmentation fault", то я бы это счел большой удачей... Хотя за пару последних лет GCJ мог сильно подрасти.

> JET работал быстрее на демке SwingSet2, чем J2SE 1.4

Какой был J2SE? Сановский 1.4.2 быстрее 1.4.1 и намного быстрее 1.4.0.

акой был J2SE?> 1.4.2 от Sun'а. Я ничего не имею против ребят из Новосибирска. Молодцы, конечно. У нас не только "индивидуалы", но и большинство учебных заведений не может ничем похвастаться.

Но мне, как Java разработчику, не нравиться, что подобные nonstandard Джавы плодятся, пропихиваются и впариваются людям (например, сейчас на JavaLobby http://www.javalobby.org идёт сассированная реклама Jet'а). Мне не нравится это потому, что Java уже довольно давно быстрая, и некоторые люди пытаются делать деньги не на разработке реальных десктопных приложений под Java, что прибавило бы языку сексуальности; а всячески стараются пережевывать слухи многолетней давности (когда ещё не было hot spot'a), по сути дискредитируя саму технологию.

Так-то оно так, но с другой стороны, прирост производительности
_действительно_ есть, хотя и не на всех приложениях.

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

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

А скомпилированный нативный код полностью утрачивает stack-trace информацию. Программу очень сложно отладить. На мой взгляд, серьёзных минусов больше, чем сомнительных плюсов.

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

Да и вообще - представьте, что программы на С были бы интерпретируемыми (ну ладно, или JIT-компилируемыми,...) - что бы из этого вышло? Jet-то тоже наверно развивается, так что через пару лет, я думаю, он будет делать все conventional JVMs на порядок.

> Какой был J2SE? Сановский 1.4.2 быстрее 1.4.1 и намного быстрее 1.4.0.

Уже не помню точно, но почти наверняка была версия 1.4.2 и на Linux, и на Win2K.

Наверное, лучше иметь сочетание JIT и AOT технологий вместе, а не что-то только одно.

Трудно даже представить себе, что каждый раз когда я запускаю на своем ноуте jEdit, его код + стандартные библиотеки перекомпилируются заново. А зачем?

Серверы, конечно, другое дело - там гораздо реже нужно перезапускать JVM. Для них JIT вполне может статься самодостаточной вещью.

Так JET и есть сочетание AOT & JIT. У них же на сайте это все написано... В частности, JEdit есть в samples. Все плугины один раз компилируются и потом многократно загружаются. Больше того, их можно перекомпилировать с самым высоким уровнем оптимизации.

Да и вообще - зачем отлаживать скомпилированную программу? Ее нужно отладить под java, скомпилировать и затем использовать.

> программы на С были бы интерпретируемыми (ну ладно, или JIT-компилируемыми,...) - что бы из этого вышло?

в теории jit быстрее native кода за счет run-time оптимизаций, и благодаря этому java в некоторых тестах делает c++, например при работе с виртуальными функциями

> Jet-то тоже наверно развивается, так что через пару лет, я думаю, он будет делать все conventional JVMs на порядок.

выходит java будет делать c++ на прядок, за счет чего ?)

Не вижу смыла в применении JET.
На сервере HotSpot Server VM по тестам быстрее да и удобней.
Для клиентского софта куда важнее память и время запуска. GCJ до ума довели бы, вот это было бы в самый раз.

>Да и вообще - зачем отлаживать скомпилированную программу?

Ну вы даёте... Многие хотят даже профилировать скомпилированную программу. Например, IntelliJ встроил YourKit Profiler прямо в IDE, и пользователи могут отправлять сообщения о проблемах с производительностью. Реальные поблемы всегда возникают в реальной обстановке, а не на рабочем столе программиста :)

Реальные проблемы, как чел выше написал, программы писать под Java, а не заниматься дурью с профилированием того, что и так быстро работает, и пытаться еще 0,5% в скорости загрузки проги в память выиграть

Я так и не прорубил, зачем отлаживать уже скомпилированную Java-программу... Может быть, все-таки объясните?

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

Ей богу, задаёте странный вопрос. Приведу пример:

1. JetBrains выпустил новую версию IntelliJ IDEA. У пользователя возникает проблема (exception, например). Пользователь exception посылает в JetBrains, и разработчики по stack trace'у понимают, где ошибка, и исправляют её.

2. Опять же JetBrains выпустил новую версию IntelliJ IDEA (со встроенным YourKit профилятором). У пользователя возникают проблемы с памятью (Java очень хорошо позволяет делать memory leak'и). Пользователь снимает снэпшот памяти и посылает его в JetBrains. Pазработчики, загрузив снэпшот в профилятор, понимают, где ошибка, и исправляют её.

Ничего подобного нельзя было бы сделать, если бы вы скомпилировали всё в native код (ни stack trace'ов, ни загружаемых в JVM плагинов)

Еще раз о том же:

stack-tracы в JET поддерживаются (уже писал кто-то об этом) плугины загружаются (для этого они и JIT compiler сделали)

Кто-нибудь из дискутирующих читал эту статью вообще?

Там английским по белому написано: для некоторых типов приложений статическая компиляция лучше (не для всех). Кому не подходит - не пользуйтесь.

Что-то я сомневаюсь сильно, что студиками этот продукт делается. У них на хоме совместный PR с Российским Аэрокосмическим Агенством выложен по поводу компиляторов для спутникового софта.

Вояки с кем попало не связываються.