Технология JIT - это диверсия?

Кроме того, на практике (мало имел дела с жабой, но), к примеру, исходники ICQ клиентов для мобильных телефонов - разные для разных моделей телефонов, то переносимости байткода всё равно не существует.

Проблема надумана. Java переносима. Если кто то использует проприетарный API вместо открытого, это не проблема Java, и уж тем более не проблема байткода.

По поводу остального - в программах тормозят циклы и ожидание I/O. Всё остальное незначительно в сравнение с этим. Циклы это в смысле участки кода, которые повторяются миллиарды раз за короткий промежуток времени, будь там цикл или рекурсия. JIT позволяет выявлять эти циклы и исполнять их оптимизированно.

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

> Единственное, что мы за это получаем

Мы получает отличные сервера приложений, да.

>Где изъян в моей логике?

Забыл про jit-cache и уход от лишних ветвлений.

программа несёт в себе компилятор

где?

программа несёт в себе компилятор (и становится тяжелее)

Вообще то, программа написанная на Java, представляет собой только байткод который может компоноваться в jar архивы или напрямую исполняться java машиной. JRE установленная у юзера, позаботиться чтобы байткод был скомпилирован в нативный код.

время отклика увеличивается. Вызов компилятора приводит к неожиданным затратам CPU, замена кода должна производиться с какой-то блокировкой (хотя и небольшой)

Это самое время отклика будет низким только при первом обращении к данному участку кода. JIT скомпилирует его в нативный код и сохранит результат выполнения в памяти для последующего вызова.

Так уж не знаю где Вы увидели подвох в JIT компиляции, как по мне только одни плюсы.

а почему у вас JIT только с жабой ассоциируется?

Просто я изучаю Java. Естественно JIT компиляция есть и в .NET,Python, etc.

> Проблема надумана. Java переносима
Это не проблема, а просто особенность одной из очень немногих программ на Java, с которыми я имел дело. Почему-то так складывается, что нужные мне программы обычно написаны на других языках. А для мобильников, кроме Java, ничего и нет, поэтому просто нет выбора.

По поводу остального - в программах тормозят циклы и ожидание I/O.

Смелое высказывание. Похоже на религиозную пропаганду. Можете набросать схему доказательства? Или цифры приведёте?

JIT позволяет выявлять эти циклы и исполнять их оптимизированно.

А если мы возьмём и сразу скомпилируем всю программу, запишем её в исполняемый файл, получится хуже? Кстати, JIT - это далеко не только Java.

>>Где изъян в моей логике?

Забыл про jit-cache и уход от лишних ветвлений.

Что это?

программа несёт в себе компилятор

где?

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

http://shootout.alioth.debian.org/u64/benchmark.php?test=all&lang=lua&lang2=l...

Пост не читал.

> А если мы возьмём и сразу скомпилируем всю программу, запишем её в исполняемый файл, получится хуже?

Нет, но и сильно лучше не получится. В программах тормозят алгоритмы. Если упираешься в скорость байткода - значит, выбрал неправильный язык.

> Это самое время отклика будет низким только при первом обращении к данному участку кода.
Похоже, Вы не понимаете, что такое JIT. У Вас есть три попытки исправить процитированную фразу.

Ну, тот факт, что большинство интерпретируемых программ-таки ускоряется при использовании JIT, очевиден по существующему ПО.

Кроме того:

- мы запускаем программу как интерпретируемую, т.е. гарантирована только скорость работы интерпретируемой программы.

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

Если же интерпретируемая программа не реального времени, а обычная, то там в любом случае в произвольном месте могут возникнуть задержки. «gc невовремя запустился», у интерпретатора кончилась память, а malloc оказался медленным, и так далее.

- программа несёт в себе компилятор (и становится тяжелее)

Она же не сама несет в себе компилятор, интерпретатор несет в себе компилятор.

- программа постоянно запущена как бы под профайлером

В жабе, например, «профайлер» всего лишь считает, сколько раз вызван метод, и когда уже достаточно много раз, он компилируется. Это незначительная трата памяти по сравнению со всем остальным. Иногда, конечно, оценивают более сложными способами, но обычно перед началом выполнения. В любом случае, нормальные программисты, увидев по тестам, что проще компилировать сразу все, чем пользоваться профайлером, который они написали, открутят этот профайлер.

время отклика увеличивается

Чем это отличается от первого пункта?

надёжность снижена. Ошибки самой реализации JIT могут вылезти в произвольное время и их появление зависит от полного пути исполнения программы. Т.е., их крайне сложно диагностировать.

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

Единственное, что мы за это получаем - переносимость байткода.

Так что мы сравнивали, байткод и нативную компиляцию или JIT и чистую интерпретацию?

Это делает компилятор. Может быть, он находится в рантайм-среде.

Что значит может быть? Естественно он находиться в среде исполнения (JRE например). Стоит это оперативной памяти, зато мы получаем переносимость между платформами без нужды переписывать код или компилировать его в нативный код для каждой платформы.

http://shootout.alioth.debian.org/u64/benchmark.php?test=all&lang=gcc&amp...

Это самое время отклика будет высоким только при первом обращении к данному участку кода.

fixed

я тоже не шибко верю в JIT

но:

- компилятор из байт-кода это фигня и может лежать в либе

- профайлить не обязательно, можно раз в 100 мкс смотреть «где мы?» и возможно расставлять или снимать 2 счетчика

- время отклика увеличивается гораздо сильнее из-за сборки мусора :-)

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

- переносимость байткода действительно не нужна

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

А что, это такая непомерная тяжесть - скомпилировать один раз код?

Это самое время отклика будет высоким только при первом обращении к данному участку кода

Первая попытка неудачна.

> Проблема надумана. Java переносима. Если кто то использует проприетарный API вместо открытого, это не проблема Java, и уж тем более не проблема байткода.

Проблема надумана. Интерпретатор кода x86 переносим. Если кто то использует свой ассемблер вместо х86, это не проблема х86, и уж тем более не проблема интерпретатора.

По поводу остального - в программах тормозят циклы и ожидание I/O.

Смелое высказывание. Похоже на религиозную пропаганду. Можете набросать схему доказательства? Или цифры приведёте?

Мне это очевидно. Одна команда машинного кода выполняется строго детерминированное время, кроме всяких манипуляций со строками, которые компиляторами не используются. Значит если у нас процессор за секунду может выполнять 10 миллиардов команд, то он их либо выполнит, либо какой то процент времени будет ждать на I/O. В типичной программе размер исполняемой части значительно меньше 10 миллиардов, поэтому очевидно, что либо она выполнится быстрее секунды, либо какие то участки исполняемой части будут выполняться чаще других. Ну и мой, так скажем, опыт написания программ, говорит, что чаще всего какие то участки занимают на много порядков больше процессорного времени, чем остальной код. И именно их оптимизация позволит дать максимальный выигрыш в производительности.

Цифр нет, в этом вопросе я доверяю инженерам Sun, MS и сотням диссертаций, написанных на эту тему.

А если мы возьмём и сразу скомпилируем всю программу, запишем её в исполняемый файл, получится хуже? Кстати, JIT - это далеко не только Java.

Может хуже, может лучше. JIT имеет преимущество в том, что потенциально он обладает большей информацией, нежели обычный компилятор. Например при компиляции условного выражения компилятор может сгенерирвать более эффективный код, если будет знать вероятность выполнения условия. В gcc для этого используются подсказки - программист пишет, какой по его мнению, результат условного выражения будет типичным для этого участка. Java может эту статистику собрать автоматически. Ну и очевидное преимущество - достаточно умный JIT может генерировать новейшие инструкции процессора, компилятор себе этого позволить обычно не может: программа должна выполняться не только на этой машине но и на других.

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

>Что это?

Кэш нативного кода + уменьшенное число ветвлений и повышенное cache-locality.

The HP project Dynamo was an experimental JIT compiler where the bytecode format and the machine code format were of the same type; the system turned HPA-8000 bytecode into HPA-8000 machine code. Counterintuitively, this resulted in speed ups, in some cases of 30% since doing this permitted optimizations at the machine code level, for example, inlining code for better cache usage and optimizations of calls to dynamic libraries and many other run-time optimizations which conventional compilers are not able to attempt.

В обоих случаях это чего-то стоит.

Тебе жалко чтоль?

Первая попытка неудачна.

Да неужели? При первом обращении к участку кода JIT скомпилирует его в нативный и сохранит этот нативный код в памяти. Как думаете скорость будет такая же, как при первом обращении?

профит JIT в переносимости и скорости работы, сравнимой со скомпилированным бинарником.

>Проблема надумана. Java переносима. Если кто то использует проприетарный API вместо открытого, это не проблема Java, и уж тем более не проблема байткода.

Вообще-то, разные версии J2ME действительно не 100%-совместимы

> По поводу остального - в программах тормозят циклы и ожидание I/O. Всё остальное незначительно в сравнение с этим. Циклы это в смысле участки кода, которые повторяются миллиарды раз за короткий промежуток времени, будь там цикл или рекурсия.

(я так понял, под I/O ты понимаешь обмен с файлами, сокетами, но не оперативкой)

Если бы это была правда, то скорость проца не увеличивалась бы при наращивании кэша L1/L2

и как раз на процах с малым кэше что ява, что xul тормозят

>профит JIT в переносимости и скорости работы, сравнимой со скомпилированным бинарником.

а при длительной работе и хорошем качестве JIT - с PGO-оптимизированным бинарником

> По поводу остального - в программах тормозят циклы и ожидание I/O. Всё остальное незначительно в сравнение с этим. Циклы это в смысле участки кода, которые повторяются миллиарды раз за короткий промежуток времени, будь там цикл или рекурсия.

(я так понял, под I/O ты понимаешь обмен с файлами, сокетами, но не оперативкой)

Если бы это была правда, то скорость проца не увеличивалась бы при наращивании кэша L1/L2

и как раз на процах с малым кэше что ява, что xul тормозят

> А что, это такая непомерная тяжесть - скомпилировать один раз код?

Stable API Nonsense. и это касается не только ведра, а и кучи библиотек.

> Цифр нет, в этом вопросе я доверяю инженерам Sun, MS и сотням диссертаций, написанных на эту тему.

мнение якобы «инженеров» (а точнее, маркетологов) ты слышал

а вот какие из сотен диссертаций ты читал? хотя бы abstract-ы? кинь ссылки

>Я вот думаю, а есть ли хоть один пример, когда JIT имеет смысл.

Разработчики современных браузерных JS-движков смотрят на тебя как на...

> Разработчики современных браузерных JS-движков смотрят на тебя как на...

говноязык требует костылей, это естественно

мнение якобы «инженеров» (а точнее, маркетологов) ты слышал

Ну покажи мне мнения не якобы инженеров, интересно почитать. Пока что я тут слышу «а мне кажется, что вот если без всех этих номодных штучек то оно может и быстрее даже будет, по старинке то».

Некоторые ссылки есть тут.

> Ну, тот факт, что большинство интерпретируемых программ-таки

ускоряется при использовании JIT

По сравнению с просто байт-кодом - возможно. А по сравнению с такой же программой, но которую заранее скомпилировали целиком? Спорю на два кило бананов, что JIT сольёт.

Так что мы сравнивали, байткод и нативную компиляцию или JIT и чистую интерпретацию?

Я бы хотел сравнить то, что можно было сделать и то, что было сделано на самом деле. Поскольку компилятор на целевой машине всё равно есть, то я предполагаю, что наиболее выгодным будет скомпилировать всю программу один раз целиком, в момент инсталляции, как это делается для программ на C. Тема начата, чтобы найти возможные изъяны в моей точке зрения. Пока что все мне объясняют, что 2х2=4, а некоторые - что 2х2=3.

Она же не сама несет в себе компилятор, интерпретатор несет в себе компилятор

Во всяком случае, компилятор должен находиться в оперативной памяти.

Да и ошибки интерпретатора могут вылезти в произвольное время

Если функция падает из-за ошибки JIT, то эта ошибка будет срабатывать только после того, как эта ф-я будет скомпилирована JIT. Отладка будет намного сложнее, т.к. ошибка приобретёт «плавающий» характер.

В жабе, например, «профайлер» всего лишь считает, сколько раз вызван метод, и когда уже достаточно много раз, он компилируется. Это незначительная трата памяти по сравнению со всем остальным.

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

В любом случае, нормальные программисты, увидев по тестам, что проще компилировать сразу все, чем пользоваться профайлером, который они написали, открутят этот профайлер.

А есть ли такая возможность, например, в случае java? Могу ли я скомпилировать jar или как они там называются, в бинарный файл с нативным кодом? Я знаю, есть ключ java -server, но он запускает компилятор при каждом запуске программы. Это, конечно, может оказаться очень плохо по производительности, поскольку компиляция - это сам по себе процесс нетривиальный.

У тебя всё равно нет выбора, если хочешь играть по-крупному.

Пока что я тут слышу «а мне кажется, что вот если без всех этих номодных штучек то оно может и быстрее даже будет, по старинке то».

не, пока что ты слышишь че-то похожее на аргументы, а не высказывания типа «а это потому, что нам так учительница инженеры sun сказали!!!

ну и я тебе предлагаю высказывать тоже аргументы

> Цифр нет, в этом вопросе я доверяю инженерам Sun, MS и
Ты доверяешь продавцам, у которых цель - продать тебе что-то.

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

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

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

Ага, вот это - второе существенное и новое, что я прочитал в этой теме. Спасибо.

Ну и очевидное преимущество - достаточно умный JIT может генерировать новейшие инструкции процессора

Это - не преимущество JIT. То же самое может сделать и «статический» компилятор, если в нём есть соответствующие переключатели.

>По сравнению с просто байт-кодом - возможно. А по сравнению с такой же программой, но которую заранее скомпилировали целиком?

А, вот как. Так и надо было сразу сказать. Потому что из первой половины вашего сообщения кажется, что вы сравниваете JIT и интерпретацию. А если вы сравниваете с нативным кодом, почему не сравниваете, например, ahead-of-time-компиляцию при каждом запуске?

Да, и это тогда уже почти холиварная тема, я в ней участвовать не хочу.

В любом случае, нормальные программисты, увидев по тестам, что проще компилировать сразу все, чем пользоваться профайлером, который они написали, открутят этот профайлер.

А есть ли такая возможность, например, в случае java?

В оригинальной жабе нет, но технологии компиляции JAR в нативный код разрабатываются. Есть GCJ, но он только до версии Java 1.4, дальше как-то плохо. Есть Excelsior JET, но он проприетарный и недешевый.

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

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

Нет, он не напрямую влияет на запуск компилятора.

> Вообще-то, разные версии J2ME действительно не 100%-совместимы
Спасибо!

> Смелое высказывание. Похоже на религиозную пропаганду. Можете набросать схему доказательства? Или цифры приведёте?

Неприятие этой «пропаганды» это отсуствие здравого смысла, возьмите профайлер и пройдитесь по программе, будут вам и цифры и всё. Или книжки почитайте, их не мало.

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

А если мы возьмём и сразу скомпилируем всю программу, запишем её в исполняемый файл, получится хуже?

да, программа станет непереносима, а это EPIC FAIL.

> - переносимость байткода действительно не нужна

опишите 2 способа действительно защищённой аутенфикации (сейчас это можно реализовать апплетом), без переносимости это не реально.

> Пока что я тут слышу «а мне кажется, что вот если без всех этих номодных штучек то оно может и быстрее даже будет, по старинке то».

и вовсе не обязательно «по-старинке»

в частности, анализ и частичная пересборка программы во время запуска (например, развиртуализация функций, возможно escape-анализ) вполне возможно полезен (и мог бы делаться в че-то типа llvm); вот только я бы не назвал это JIT

> Где изъян в моей логике?

Вот:

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

«Вызов компилятора приводит к неожиданным затратам CPU» - а его работа экономит время CPU.

В общем, басня про Ахилла и черепаху.

> В оригинальной жабе нет, но технологии компиляции JAR в нативный код разрабатываются.

А теперь ставим себя на место разработчиков Java. Могли они сделать это сразу? Могли, конечно, ведь JIT - сложнее, чем просто компилятор. JIT - это профайлер, соглашения, гарантирующее интероперабельность интерпретируемого и компилируемого кода, а также блокировки, гарантирующие, что код будет не вызван в момент его подмены. По сравнению с этим, записать код в файл - это задача намного более простая. Почему они пошли окольным путём?

Нет, он не напрямую влияет на запуск компилятора.

А как?

>вот только я бы не назвал это JIT

я бы назвал это сочетанием JIT и AOT

> опишите 2 способа действительно защищённой аутенфикации (сейчас это можно реализовать апплетом), без переносимости это не реально.

что значит «действительно защищённой аутенфикации»?

и чем не подходит https + либо сигнатура сертификата, либо подпись одного из корневых СА?

>В оригинальной жабе нет, но технологии компиляции JAR в нативный код разрабатываются. Есть GCJ, но он только до версии Java 1.4, дальше как-то плохо. Есть Excelsior JET, но он проприетарный и недешевый.

VMKit еще, но он пока в разработке

> По сравнению с просто байт-кодом - возможно. А по сравнению с такой же программой, но которую заранее скомпилировали целиком? Спорю на два кило бананов, что JIT сольёт.

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

Тема начата, чтобы найти возможные изъяны в моей точке зрения. Пока что все мне объясняют, что 2х2=4, а некоторые - что 2х2=3.

изьяны в том, что вы владеете далеко не полной информацией по теме ;) о чём вам и говорят.

Если функция падает из-за ошибки JIT, то эта ошибка будет срабатывать только после того, как эта ф-я будет скомпилирована JIT. Отладка будет намного сложнее, т.к. ошибка приобретёт «плавающий» характер.

можно работающий пример падения функции из-за ошибки JIT? Или хотя бы ссылки на людей, которые сталкивались, пока это похоже на сказки). Тем более что в механизмы JIT компиляции встроенны механизмы возвращения к нескомпилированной версии.

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

ну поищите уже списки рассылки и статьи на эту тему, ведь не от балды в java решения принимаются

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

Потому что в джаве есть понятие ClassLoader, по-этому без JIT не обойтись. Загрузка классов на лету (причем не обязтаельно из файлов, байт-код может генерироваться на лету) что вполне себе используется.

>да, программа станет непереносима, а это EPIC FAIL.

OK, допустим ты написал свою программу на Java SE 6. Как запустить ее на Mac OS/PPC?