неужели сами с нуля написали? неужели полностью совместим? и чтото не нашел я тестов по производительности их JRE может плохо искал..

да и еще а где можно найти для Swing компонентов сторонние UI представители, хоца посмотреть какие еще морды бывают у явы :-)

http://www.excelsior-usa.com/jetlatest.html

Раньше оно сначало перекомпилировало всю jre в so(dll),
потом компилировало приложение, а потом это приложение
запускалось только на этой машине.
Компиляция jre шла ~2ч (P4 2800),
машин где надо компилировать ~ 20,
особого роста производительности незаметил.
Стоит это чудо от 250-2400$ + лицензи на каждую машину (как я понял)

Вопрос : зачем оно надо ?

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

Я тестил эту штуку версии 3.х. Производительность Свинг-приложения типа SwingSet, действительно, высокая. Формы открываются мгновенно. Требования по объему памяти такие же или даже больше, как и в обычном JRE. Разделения кода не происходит: каждое запущенный экземпляр SwingSet отъедал дополнительные 50М физической памяти (судил по уменьшению свободной памяти в системе), хотя старт приложений происходил быстрее.

Мой вывод: в большинстве случаев игра не стоит свеч. Выкачивал мустанг 51 билд. Свинг работает очень шустро.

Ветку 4.0 пробовать не хочу, так как они включили в состав пакета JRE, судя по объему в 56М.

Неплохая штука. Но на практике особо не нужна.

Компилировалось jre у меня не два часа, но тоже довольно долго. Прирост производительности (в гуе) на глаз 15-20%.

Это? http://www.excelsior-usa.com/jetdlevala.html

"НАМ ТАКОЙ ХОКЕЙ НЕ НУЖЕН!" (с)

"For the same reason, the JetPerfect Global Optimizer add-on will not be commercially available starting from Excelsior JET 4.0. This implies that you will not be able to create a single, all-inclusive binary executable for your application or component, even if you do not care about its size.

However, you will be able to create an all-inclusive directory that contains your executable and necessary runtime support files and can be deployed to other systems by a simple copy operation"

Короче, ещё одна никому не нужная поделка от "расейских" Левшей-Кулибиных

ЗЫ. Про "кулибиных" читать сюда: http://az.lib.ru/l/leskow_n_s/text_0246.shtml

Да ты, парень, настоящий кульхацкер, раз "на глаз" производительность определяешь!:) Простые смертные объект класса Date заводят, времена сравнивают.

> Но на практике особо не нужна.

Согласен.

Ребята изобрели gcj?

> Это? http://www.excelsior-usa.com/jetdlevala.html

И что характерно, как просто устанавливать в винде и целые инструкции для линукса, ещё и к readme.txt для окончательной установки отсылают.

>да и еще а где можно найти для Swing компонентов сторонние UI представители, хоца посмотреть какие еще морды бывают у явы :-)

SWT например - морда будет как у системы и работает много шустрее www.eclipse.org/swt

Ты про PLAF чтоли?

жалко, что не open source

Поздравляю тебя, Шарик.

Обычно сравнивают System.currentTimeMillis().

Если кто не знает...

Интерес к АОТ-компиляторам в целом и к сабжу в частности продиктован не проблемами производительности существующего решения -- производительности JVM более чем достаточно, а тормозят конкретные программы. Одну из причин можно узнать здесь http://jroller.com/page/slobodan?entry=object_count_impact_on_garbage

На АОТ возлагаются некоторые надежды в плане преодоления проблемы ресурсоемкости десктопных java-программ. Если jar откомпилировать в .dll/.so, то можно мапить их в адресное пространство процессов, как это делается в обычныхх приложениях. Первый кандидат на это - rt.jar.

GCJ работает, как вариант, но требутся нечто большее. Eclipse в FC4 вовсе не является нативным в полном смысле этого слова, так как плугины там всё равно в виде jar (а значит, код в режиме интерпретации). Хорошо бы было, например, иметь в JVM ClassLoader, способный компилировать jar в dll и затем прозрачно подгружать его вместо соответствующего jar. Тогда при форке процесса (запуск большого количества экземпляров одного и того же приложения в случае терминального сервера) dll подгружались бы только один раз.

> потом это приложение запускалось только на этой машине.

??? Напускаешь на скомпилированное приложение утилиту JetPackII, получаешь директорию с нужными файлами, tar+gzip ее, и таскаешь на любую машину.

Лицензия нужна только на машину где компилируешь, роялти только для многопроцессорных серверов и встроенных систем. Академические лицензии раз в пять дешевле обычных.

А русский в Новосибирске не изучают?

> на сайте компании его не раздают даже "на попробовать"

Раздают, можешь до 90 дней баловаться если зарегистрируешься, а без регистрации - 30.

http://www.excelsior-usa.com/jetdleval.html

> А русский в Новосибирске не изучают?

А софт в России покупают?

> SWT например - морда будет как у системы и работает много шустрее www.eclipse.org/swt

У кого (Swing или SWT) морда более похожа на системную, можно ещё поспорить. То же самое про скорость.

Не всё так просто, вот, например, сттатья про недостатки SWT: http://www.hacknot.info/hacknot/action/showEntry?eid=74

>> SWT например - морда будет как у системы и работает много шустрее www.eclipse.org/swt

>У кого (Swing или SWT) морда более похожа на системную, можно ещё поспорить. То же самое про скорость.

Давай поспорим ;-)

Я всегда отличал Swing от системной. Eclipse в большенстве случаев берет системные виджеты.

Другое дело, что у SWT дествительно полно проблем:

Баги (хотя в 3.1 их заметно меньше, да и у кого их нет, но в целом в SWT багов больше)
Тяжело учить (меньше пособий, да и framework сложнее (не сам SWT конечно) а JFace,GEF и сама платформа Eclipse (SWT прост, но его голым нет ризона использовать).
Переносимость (SWT хуже портируется чем SWING)
Мало специалистов.
Мало открытой документации.
Код SWT/Eclipse писал человек до этого много писавший на C++ и не потрудившийся ознакомится с Java Code Style. Некоторые вещи в угоду оптимзации сделаны через то самое место.


Из плюсов - выглядит красиво, работает быстро, много готовых компонентов, очень сильный/гибкий фреймворк для постоения Desktop приложений (IBM worklpace тому пример), почти все успешные Java Desktop программы на SWT/Eclipse/RCP.

Искренне рекомендую Alloy Look And Feel - http://www.incors.com/ Продукт коммерческий :(

> хоца посмотреть какие еще морды бывают у явы :-)
http://www.javootoo.com/

> Обычно сравнивают System.currentTimeMillis().

Ты молодец! Только глуповат слегка и исходники, как настоящий кульхацкер, никогда не смотришь:

/**
* Allocates a <code>Date</code> object and initializes it so that 
* it represents the time at which it was allocated, measured to the 
* nearest millisecond. 
*
* @see     java.lang.System#currentTimeMillis()
*/
public Date() {
    this(System.currentTimeMillis());
}

Так, что отдохни малька.:)

codex

> А русский в Новосибирске не изучают?
как иностранный как в Москве? (http://www.mk.ru/newshop/bask.asp?artid=114967)
нееет - пока не дошло до этого.;-)

There is no such resource as memory? ;-)

Кстати, девушка, мы знакомы? ;-)

>да и еще а где можно найти для Swing компонентов сторонние UI представители, хоца посмотреть какие еще морды бывают у явы :-)

jroller.com/page/gfx?entry=real_world_physics_in_swing

www.clientjava.com/blog/2005/09/21/1127330514923.html

www.jidesoft.com

www.javootoo.com

www.jgoodies.com

> There is no such resource as memory?

Нет, бабушка, не знакомы. Вы бабуля, Инглиш знаете так же "хорошо", как и Жабу. Учительница в школе "зис из ту тикетс туда блин" говорила или вы были троечницей, а? Научитесь правильно предложения строить или правильно заканчивать свою вопросительную фразу на "пиджин-инглиш", которым вы тут нас развлекли.:)

> Нет, бабушка, не знакомы.

Жаль. А то научили бы "правильно предложения строить". ;-)

Ну облажалась вы бабуля сегодня пару раз - и на старуху бывает проруха. Сами то поняли, где не то сморозили? Век живите - век учитесь.:)

Как ты? :-)

Я то нормально, а ты англицкую мову подучи. Тогда и статейки вумные читать смогешь http://www.onjava.com/pub/a/onjava/2003/06/05/java_calendar.html

хм спасибо посмотрю. а насчет у кого морда более похожа на системную у swing или swt то я знаю :-) у awt :-)

ого кажися я плохо искал

Ну ваще. Раскрыл глаза. ;-)

А теперь применим это к вопросу о измерении производительности. :-)

>Интерес к АОТ-компиляторам в целом и к сабжу в частности продиктован не проблемами производительности существующего решения -- производительности JVM более чем достаточно, а тормозят конкретные программы.

Действительно "производительности JVM более чем достаточно", однако для десктопных приложений очень важен быстрый старт и небольшое потребление ресурсов. AOT решает первую проблему и немного ослабляет ( облегчает ?) последнюю.

>Одну из причин можно узнать здесь http://jroller.com/page/slobodan?entry=object_count_impact_on_garbage

То, что чем больше обьектов, тем больше работы гц - очевидный факт. Однако в впечатление такое, что об эффективном гц в жабе никто к сожалению незаботится. Очень интересное обсуждение было в комп.ланг.лисп, где один дядька сравнимал программы рэйтрйснга для несколько десятков тысяч сфер. Были коммон-лисп, ОКэмл, Жаба, С++, СМЛ ... ОКэмл оказался быстрее Жаба в несколько раз, там возник жабоспец и посоветовал увеличить размер юнг-генерэйшн так, чтобы чтобы гц происходин убирал на порядок меньше ( юнг-генерэйшн - так как стат.гц показывала, что мусор был исключительно короткоживущий ), тогда Жаба стала практически на равных с Верблюдом, хотя и памяти стала жрать на порядок больше. ( По статистике Вебл. гц, было видно, что он действительно убитрал на порядок больше мусора ). Короче, народ сошолся во мнении, что гц в жабе реализован отстойно...

Незря моно-тим главной задачей считают минимизировать оверхед по памяти на уровне С/C++ приложений...

wiki.java.net/bin/view/Main/BetterDesktopJava

weblogs.java.net/blog/gfx/archive/2005/09/physics_laws_in.html

weblogs.java.net/blog/tball/archive/2005/09/netbeans_50_is.html

weblogs.java.net/blog/hansmuller/archive/2004/10/and_then_there.html

> ... Однако в впечатление такое, что об эффективном гц в жабе никто к сожалению незаботится. Очень интересное обсуждение было в комп.ланг.лисп ...

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

Эти ребята - просто молодцы! Рад за них. Создать такую вещь дано далеко не каждому из нас... Еще удивительно, что фирма до сих пор "новосибирская".

Они молодцы, делают феноменальный продукт по возможностям и качеству исполнения (всё делают на редкость учёные мужи, и как их ещё америка с головой не купила...)

Вобщем в "компиляторах" они смыслят гораздо больше чем остальные создатели различных других компиляторов...

/amax

Я вот сейчас ковыряю исходники j2se 5.0 на предмет встраивания туда AOT. Идея пока простая - откомпилировать hotspot-компилером классы в настивный код (это можно) и залить их в ресурсы dll/so. Потом сделать ClassLoader, берущий откомпилированные методы не из jar а из dll/so (С so будет работать, а вот про dll не знаю). Сложно это весьма в текущей архитектуре hotspot, но настроен оптимистически.

Про моно -- тоам вроде BoehmGC используется. Можно попробовать встроить его в sun jvm и посмотреть что будет, там есть интерфейсы для новых GC. Не уверен, что обнаружатся преимущества.

Они-то молодцы, но не купили их потому, что никому такая ерунда не нужна, скорость перекомпиляция в натив не увеличит, головной боли - добавит, а прелесть жабы в том, что не надо думать, в какой таргет компилять байткод - WORE (Write Once Run Everywhere)

>Про моно -- тоам вроде BoehmGC используется. Можно попробовать встроить его в sun jvm и посмотреть что будет

Ничего хорошего небудет. BoehmGC - консервативный коллектор, он незнает где искать рутов и поэтому сканирует весь RSS. Хорошо если RSS небольшой , а если несколько гигов? И генераций у него нет и не дефрагментирует он... Да и они сами собираются с него слезать.

>Идея пока простая - откомпилировать hotspot-компилером классы в настивный код (это можно) и залить их в ресурсы dll/so.

А если некоторый умник менает байт-код в классЛэудере (как например ЖБосс и некоторые АОП-ы)? Более того, если эти изменения зависят например от конфига (то есть разные от запуска к запуску)? Или кто-то генерит или меняет байт-код в рантайме чем нибудь типа АСМ-а? Тяжело будет однако ...

Ну, почему же сразу ерунда? По-моему получилась очень интересная и полезная штука. Что касается предварительной компиляции в экзешник - это лишь одно из применений, которое является, возможно, и не самым полезным, зато весьма показательным.

Насколько я понимаю, основная заслуга Excelsior - отработанная технология AOT-компиляции (у кого еще такая есть? gcj - им не ровня). Добавим еще к этому имеющуюся у них JIT-компиляцию. Теперь представим такой сценарий. Например, если предкомпилировать через AOT все системные библиотеки, то уже одно это в сочетании с обычным JIT может дать хороший прирост в скорости, особенно на этапе запуска приложений. Если еще добавить AOT-предкомпиляцию часто используемых приложений, то тогда, вообще, прирост в скорости будет еще заметнее. Здесь сразу вспоминается утилита ngen из .NET Framework.

Пока рынок Java-приложений вертится вокруг серверов и мобильных устройств, технология AOT, может быть, особо и не нужна. Однако, для десктопных Java-приложений AOT [в сочетании с JIT] был бы очень полезным.

>прелесть жабы в том, что не надо думать, в какой таргет компилять байткод

А где надо то? При первом старте АОТ скомпилил все и положил в ГАК. При всех последующих скомпиленный код берется из ГАК-а.

а как насчёт поддержки жава-цпу? просьба не кидаться тухлыми яйцами на тему его отсутствия ;)

Динамически созданные/подгруженные по сети классы обрабатываются обычным jit/hotspot

PS1. В hotspot всё плохо, эта машина дает очень большой overhead по ресурсам и для "маленьких десктопных приложений" не годится. AOT от них ждать не стоит. Можно, конечно, научить hotspot дергать код классов из ресурсов dll, но желаемой минимизации системных ресурсов не получится. Даже rt.jar class data sharing в Tiger -- обман зрения. Скорее стоит ожидать отдельную jvm оптимизированную для десктопных приложений, которая будет комбинировать JIT/AOT.

PS2. Либо, как вариант, починить JVM в gcj так, чтобы он умел более-менее нормальный JIT. Единственное, что плохо -- в gcj трудно будет получить динамический AOT в рантайме приложения так как используется стандартная для gcc схема компилятор-ассемблер-линкер.

PS3. Еще вариант, сделать из gcj с JIT-enabled VM надстройку над sun runtime, как это сделали в JET. С лицензированием вродебы должно быть всё ок.

PS4. Меня вот только что смутило в gcj (3.4.2) -- он не смог откомпилировать libgcj-*.jar.

Ну почему же, они есть. И иногда используются в embedded-решениях. Вот только производительность у них маленькая, даже если эти процессоры промасштабировать по кол-ву транзисторов до уровня Intel/AMD.