LINUX.ORG.RU
 

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


0

0

Автор рассуждает о преимуществах нативной компиляции Java программ и о производительности natively-compiled Swing-based приложений.

Рассматриваются два static Java компилятора: GCJ и Excelsior JET.

>>> Статья

anonymous ()
Проверено: Demetrio (02.11.2004 17:45:33)

СКАЖИ СВОЕМУ КОМПЬЮТЕРУ, ЧТОБЫ ЗАПЕР ДВЕРЬ

любительская автоматизация; устройство с открытой прошивкой
исходные тексты всех программ, открытые библиотеки
http://www.unicontrollers.com/products/unc01x

[#]  

Re: Статья в журнале LinuxWorld "Improving Swing Performance"

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

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

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

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

**** ()
[#] Ответ на: Re: Re: Статья в журнале LinuxWorld "Improving Swing Performance" от dave 02.11.2004 19:42:24  

Re: Re: Re: Статья в журнале LinuxWorld "Improving Swing Performance"

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

** ()
[#] Ответ на: Re: Re: Re: Статья в журнале LinuxWorld "Improving Swing Performance" от arum 02.11.2004 20:02:54  

Re: Re: Re: Re: Статья в журнале LinuxWorld "Improving Swing Performance"

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).

anonymous ()
[#]  

Re: Статья в журнале LinuxWorld "Improving Swing Performance"

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

anonymous ()
[#]  

Re: Статья в журнале LinuxWorld "Improving Swing Performance"

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

anonymous ()
[#] Ответ на: Re: Статья в журнале LinuxWorld "Improving Swing Performance" от anonymous 03.11.2004 8:15:12  

Re: Re: Статья в журнале LinuxWorld "Improving Swing Performance"

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

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

()
[#] Ответ на: Re: Re: Статья в журнале LinuxWorld "Improving Swing Performance" от sleep-walker 03.11.2004 8:28:34  

Re: Re: Re: Статья в журнале LinuxWorld "Improving Swing Performance"

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

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

anonymous ()
[#] Ответ на: Re: Статья в журнале LinuxWorld "Improving Swing Performance" от anonymous 03.11.2004 8:15:12  
dave

Re: Re: Статья в журнале LinuxWorld "Improving Swing Performance"

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

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

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

***** ()
[#] Ответ на: Re: Re: Re: Статья в журнале LinuxWorld "Improving Swing Performance" от pitekantrop 03.11.2004 13:05:30  

Re: Re: Re: Re: Статья в журнале LinuxWorld "Improving Swing Performance"

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

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

anonymous ()
[#] Ответ на: Re: Re: Re: Re: Статья в журнале LinuxWorld "Improving Swing Performance" от anonymous 03.11.2004 14:34:39  

Re: Re: Re: Re: Re: Статья в журнале LinuxWorld "Improving Swing Performance"

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

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

anonymous ()
[#] Ответ на: Re: Re: Re: Re: Re: Статья в журнале LinuxWorld "Improving Swing Performance" от anonymous 03.11.2004 14:43:56  

Re: Re: Re: Re: Re: Re: Статья в журнале LinuxWorld "Improving Swing Performance"

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

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

anonymous ()
[#] Ответ на: Re: Re: Re: Re: Re: Re: Статья в журнале LinuxWorld "Improving Swing Performance" от anonymous 03.11.2004 14:49:50  

Re: Re: Re: Re: Re: Re: Re: Статья в журнале LinuxWorld "Improving Swing Performance"

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

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

anonymous ()
[#] Ответ на: Re: Re: Re: Статья в журнале LinuxWorld "Improving Swing Performance" от pitekantrop 03.11.2004 13:05:30  
dave

Re: Re: Re: Re: Статья в журнале LinuxWorld "Improving Swing Performance"

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

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

***** ()
[#] Ответ на: Re: Re: Re: Re: Re: Re: Re: Статья в журнале LinuxWorld "Improving Swing Performance" от anonymous 03.11.2004 16:05:13  
dave

Re: Re: Re: Re: Re: Re: Re: Re: Статья в журнале LinuxWorld "Improving Swing Performance"

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

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

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

***** ()
[#] Ответ на: Re: Re: Re: Re: Re: Re: Re: Re: Статья в журнале LinuxWorld "Improving Swing Performance" от dave 03.11.2004 16:23:21  

Re: Re: Re: Re: Re: Re: Re: Re: Re: Статья в журнале LinuxWorld "Improving Swing Performance"

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

anonymous ()
[#] Ответ на: Re: Re: Re: Re: Re: Re: Статья в журнале LinuxWorld "Improving Swing Performance" от anonymous 03.11.2004 14:49:50  

Re: Re: Re: Re: Re: Re: Re: Статья в журнале LinuxWorld "Improving Swing Performance"

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

anonymous ()
[#] Ответ на: Re: Re: Re: Re: Re: Re: Re: Статья в журнале LinuxWorld "Improving Swing Performance" от anonymous 03.11.2004 16:05:13  

Re: Re: Re: Re: Re: Re: Re: Re: Статья в журнале LinuxWorld "Improving Swing Performance"

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

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

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

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

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



** ()
[#] Ответ на: Re: Re: Re: Re: Re: Re: Re: Статья в журнале LinuxWorld "Improving Swing Performance" от anonymous 03.11.2004 16:34:21  

Re: Re: Re: Re: Re: Re: Re: Re: Статья в журнале LinuxWorld "Improving Swing Performance"

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

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

anonymous ()
[#] Ответ на: Re: Re: Re: Re: Re: Re: Re: Re: Статья в журнале LinuxWorld "Improving Swing Performance" от anonymous 03.11.2004 18:52:52  

Re: Re: Статья в журнале LinuxWorld "Improving Swing Performance"

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

anonymous ()
[#] Ответ на: Re: Re: Re: Re: Re: Re: Re: Re: Re: Статья в журнале LinuxWorld "Improving Swing Performance" от anonymous 05.11.2004 9:07:53  

Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Статья в журнале LinuxWorld "Improving Swing Performance"

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

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

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

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

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

anonymous ()
[#] Ответ на: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Статья в журнале LinuxWorld "Improving Swing Performance" от anonymous 05.11.2004 10:15:13  

Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Статья в журнале LinuxWorld "Improving Swing Performance"

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

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

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

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

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

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

anonymous ()
Java