Для виртуальной машины Dalvik (http://www.dalvikvm.com/), используемой для выполнения приложений на мобильной платформе Android, разработан (http://groups.google.com/group/android-platform/msg/662b32b9...) экспериментальный прототип JIT-компилятора, преобразующего во время исполнения приложения Java байткод в машинные инструкции. Предварительное тестирование показало (http://groups.google.com/group/0xlab-devel/msg/513fb96a4e0f473f), что использование представленного JIT-компилятора позволит ускорить выполнение приложений в среднем в три раза.
Результаты тестирования:- Sieve: было 956, стало 2345
- Loop: было 783, стало 3629
- Logic: было 1099, стало 5618
- String: было 2019, стало 4328
- Float: было 819, стало 1495
- Method: было 1103, стало 1954
- В среднем: было 1069, стало 2907URL: http://groups.google.com/group/android-platform/msg/662b32b9...
Новость: http://www.opennet.me/opennews/art.shtml?num=24304
Браво :)
Но не кажется ли вам что на телефонах с Java положенно быть ARM-процессорам с Jizelle и попросто её выполнять аппаратно ? А второй вопрос - сколько же этот JIT начинает кушать памяти, когда в телефоне работают несколько приложений одновременно. Её там, мало, не то что гигабайты у нас на десктопах.
под андройдом работают не только мобильные телефоны
Да, также огромные кластеры, на которых можно запускать тетрис на яве.
Не факт, что Жазель схавает далвиковский код.
И кстати, жазель всего лишь ускоряет интерпретатор, но полноценному jit-у все равно заметно уступает.
на сониэриксонах к примеру вся жава ускоряется аппаратно
нормальные языки не надо ускорять
>нормальные языки не надо ускорятьаноним путает язык и его конкретную реализацию
Не я первый сказал про ускорение жавы. А вообще, покажи мне реально работающую и использующуюся реализацию жавы без VM и JIT.
>Не я первый сказал про ускорение жавы. А вообще, покажи мне реально
>работающую и использующуюся реализацию жавы без VM и JIT.
>http://www.excelsior-usa.com/articles/java-to-exe.htmlГлупый? Оборачивалка .jar в .exe?
>Глупый? Оборачивалка .jar в .exe?Чтобы нынче быть умным достаточно не ходить по ссылкам и не знать английского (ну и в предмете разговора не разбираются, но это, по нынешним временам мелочи).
Tools
There used to be half a dozen AOT Java compilers on the market in the year 2000, but the only two that have survived are Excelsior JET and GCJ (GNU Compiler for Java). You will find a side-by-side comparison of these products in the Bonus Features section below.
If you are in the embedded field, check out Aonix PERC, which targets J2ME CDC and also has limited support for J2SE 1.3.
> but the only two that have survived are Excelsior JET and GCJВоооот, этого я от вас и добиваюсь. А теперь сами же почитайте как они "работают", что поддерживают и сколько стоят.
>Воооот, этого я от вас и добиваюсь. А теперь сами же почитайте
>как они "работают", что поддерживают и сколько стоят.Excelsior is a Java Authorized Licensee, and its product uses the licensed Sun's implementations of the latest Java SE 6 API. Excelsior JET is certified Java Compatible on a number of Windows and Linux platforms. The legacy J2SE 5.0 API is also supported.
Я сказал прочитайте, а не копипастите сюда не имеющее отношение к вопросу строчки.
>А вообще, покажи мне реально
>работающую и использующуюся реализацию жавы без VM и JIT.Microsoft J++, GCJ. Ещё?
Нет, нет, нет. Отдыхай.
Сразу с этого надо было начинать. Ведь приложение можно сначала отjitить а потом и запускать уже, не думаю что так больше памяти кушаться будет... И кэширование jitнутого кода можно предусмотреть...Будет JIT - будет и интерес к платформе.
>Ведь приложение можно сначала отjitить а потом и запускать уже,Это называется AOT, а не JIT.
JIT совместно с VM работает в реальном времени и контролирует ресурсы при трансляции байткода и исполнении нативного кода.
Автору новости — при публикации имеет смысл указывать единицы измерения (в тесте).
В данном случае есть просто столбцы ничего не значащих цифр.
видимо, там все измеряется в попугаях
А если тесты на сях в нативном коде прогнать - они порвут всех в 20 раз тогда? :) Браво, гугль. Факофф короче с велосипедами, ARM и без того дохленькие чтобы их еще и тормозными ява-виртуалками просаживать.P.S. заметьте, при таком ускорении жабисты про ява-машину без JIT орали с пеной у рта что она не тормоз. Во лицемеры...
>А если тесты на сях в нативном коде прогнать - они порвут
>всех в 20 раз тогда? :) Браво, гугль. Факофф короче с
>велосипедами, ARM и без того дохленькие чтобы их еще и тормозными
>ява-виртуалками просаживать.Я тебе больше скажу — ни нибуя не понимаешь предназначение виртуальных машин, их место и роль.
>P.S. заметьте, при таком ускорении жабисты про ява-машину без JIT орали с
>пеной у рта что она не тормоз. Во лицемеры...Если бы ты почитал, КАК организовано выполнение байткода на Jazelle, то ПОНЯЛ бы, что не весь байткод способен непосредственно выполняться на этом ядре. А значит, для какой-то части байткода нужен либо интерпретатор (встроен в Dalvik), либо JIT, чтобы байткод, оттранслированный в нативный код, работал на ARM, а не в Jazelle.
Место и предназначение их - на свалке истории. Смысл там был только один - портабельный байткод, который в эпоху опенсорса не только не нужен, но и вреден. А если учесть кошмарный оверхед...
Ну да, еще голубые мечты о защищенной среде исполнения а-ля singularity. Только это все к реальности никакого отношения не имеет.
Jazelle это вообще смешнейшая штука - костыль, поддерживающий костыль.
>Только это все к реальности никакого отношения не имеет.Зато к реальности имеет отношение скорость разработки, отладки и сопровождение.
Нативный код в этом деле сосёт, как никогда.
>Зато к реальности имеет отношение скорость разработки, отладки и сопровождение.
>Нативный код в этом деле сoсёт, как никогда.Вот это, называется, ляпнул. Разницу между исходником и тем, во что он компилится, не видим?
>Вот это, называется, ляпнул. Разницу между исходником и тем, во что он
>компилится, не видим?То ж iZEN. Нашли, тоже мне, с кем беседовать.
>>Зато к реальности имеет отношение скорость разработки, отладки и сопровождение.
>>Нативный код в этом деле сoсёт, как никогда.
>
>Вот это, называется, ляпнул. Разницу между исходником и тем, во что он
>компилится, не видим?Видим. Ведь работает не исходник, а нативный код.
Покажите мне средство удалённой отладки для C++, тогда и поговорим.
>Нативный код в этом деле сосёт, как никогда.Действительно, дебилам удобнее играть в песочек в их песочнице :). А интеллект большинства жава програмеров сразу заметен, не в обиду оным (да, я видал пару вменяемых жабистов, но найти их не сильно проще чем снег пустыне Сахара).
Только я посмотрю как у вас не будет сосать ваша песочница когда вам надо будет выжать приличную скорость. Да, там и с профайлером обтрахаешься и прочая - потому что когда и без того тормозной проц тормознут дебильной и жутко тормозной виртуалкой - только и остается что дрочить профайлер до упора и изгаляться.
>Я тебе больше скажу — ни нибуя не понимаешь предназначение виртуальных машин,
>их место и роль.Да нет, почему же. Я прекрасно понимаю их роль - не пускать юзера в его систему любой ценой, предоставив кастрированное тормозное окружение где юзера можно оставить в его песочнице, не пустив в систему.А то некоторые операторы и компании очень любят навязывать свои "уникальные" услуги в ножом к горлу, так что вмешательство в систему никак не можно, а то юзеры еще чего доброго смогут отказаться от такого "благодетельства". Никак не можно! :)
>Если бы ты почитал, КАК организовано выполнение байткода на Jazelle,
1) JFYI, нормальная документация на Jazelle AFAIK недоступна простым смертным...
2) AFAIK оно может ускорить только некоторые операции.
3) Для гуглевского мега-велосипеда она, AFAIK, бесполезна.>А значит, для какой-то части байткода нужен либо интерпретатор (встроен в
>Dalvik), либо JIT, чтобы байткод, оттранслированный в нативный код, работал на
>ARM, а не в Jazelle.Много умных слов но, увы, мало толку... ;P. Надо быть кретином чтобы не понять насколько сие сольет простому откомпиленому под платформу коду. А попытки вытянуть сравнимую с нативным кодом скорость на такой платформе - совершенно нереальный трах из области ракетных наук: если вам надо на гугл-велосипеде приличную скорость (а кому не надо то? Авторам многочисленных ноутпадов?), будет больше борьбы с идиотской платформой чем нормального програминга. Армы и так задохлики и просадить их еще минимум в несколько раз в узких местах - идиотизм тотальный! И это идеальный случай, когда там крутой JIT генерящий код на уровне хорошего сишного компилера. Слив - чисто на рантайм-проверках и т.п. которые в глубоких циклах создадут жопу. На сях(++) то мы заранее может проверить не вылезет ли вон то за буфер и не крутить проверки в цикле. Но на яве такое не канает - там медвежья услуга предоставляется с ножиком к горлу. И чтобы отказаться от нее - придется эпично потрахаться. А если не отказываться - в всех узких местах слив раза в 3 будет обеспечен, чудес не бывает. По факту я так смотрю - гугле пока и до этого как пехом до пекина.
А я-то думал, что он там с самого начала был.