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

>А потом по работе пришлось поработать с java и понял что мир полон тупых красноглазиков, кричащих «лисп!лисп!лисп!» на каждом углу, а по факту не имеющих выполенных нормальных проектов.

для лиспа тоже есть реализации JIT :)

>В GCC, в Open64 и во многих других компиляторах, с которыми я имел дело, оптимизации начинаются только уже на очень низком уровне, когда метаданных уже намного меньше чем в байткоде JVM или CLR.

так что вся надежда на LLVM, где эта информация не теряется :)

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

«Настоящий фортрановский программист напишет фортрановскую программу на любом языке»

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

Видишь ли проблема в том, что один человек не способен создать настолько серьезную нагрузку, что бы заметить фоновую работу JIT. У меня достаточно много жавногго софта на компе (взять хотя бы Idea), так вот никакиз тормозов не заметно при старте. Эклипс в целом вообще летает. YourKit неотличить от плюсовой проги по отклику GUI.

А теперь представь выкладку релиза крупного проекта под нагрузкой. Все может запросто стать раком.

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

Тем не менее спасибо за ссылку. Мне, как человеку слабо образованному, дюже интересно это почитать.

> Сам пошутил, сам посмеялся, умничка.

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

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

Разочарую тебя, слабака, но из трехадресного GIMPLE тоже надо восстанавливать. И из любого другого промежуточного представления, которое используется для оптимизаций, тоже надо восстанавливать. В природе не существует ни единого компилятора, где были бы оптимизации на уровне AST.

Прежде чем в тебе твоя детсадовская гордость взыграет, и ты полезешь по идиотски возражать, советую все же найти контр-пример. Найдешь компилятор, который делает сложные оптимизации на уровне AST, такие, какие нельзя сделать на уровне последющей VM, возьму свои слова обратно. До тех же пор ты просто самоуверенный (без малейших на то оснований) неуч.

Да. А что, есть люди, которые этого не передставляют?

Ты, например. Небось, считаешь, что CLR это стековая VM, да?

Представлял бы, не смел бы нести чушь, что в CLR метаданных меньше чем в GIMPLE или в LLVM IR.

> так что вся надежда на LLVM, где эта информация не теряется :)

Расскажи, что же именно в LLVM «не теряется»?

Посмотри, как в LLVM компилится C++ - все те же структуры, пляски с v-table, и т.п.

И точно так же, все базовые конструкции языка транслируются в кучку низкоуровневых инструкций, которые существенно более низкоуровневые чем в том же CLR.

так что вся надежда на LLVM, где эта информация не теряется :)

LLVM вообще-то как раз JIT и умеет.

>LLVM вообще-то как раз JIT и умеет.

AOT тоже :)

>Расскажи, что же именно в LLVM «не теряется»?

Полная информация об оригинальном исходном коде. У них это называется lifelong compilation

http://llvm.org/pubs/2004-01-30-CGO-LLVM.html

Там этой информации не больше чем в .pdb-,файлах в .net, и оптимизациям она не досткпна. Никакого ast с собой ir не тащит.

Забавный разговор получился.

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

С другой стороны, высокоуровневые представления не универсальны. Не подходит JVM/СLR-овский call virtual для реализации виртуального вызова в каком-нибудь языке не похожем на Visual Basic.

Что же делать? Уверен, товарищу анониму есть чем с нами поделиться. Хочется резюме.

А кого сношают языки, не похожие на VB? Разговор то про уровень VM и оптимизации. В .net оптимизатор может заменить виртуальный вызов на статический, в llvm уже не сможет, метаданные потеряны.

Как раз наоборот, в SBCL много чего допилили, и продолжают пилить.

Предварительно убрав все то, что не осилили понять. То есть, почти все.

Если не трудно - расскажите, что именно?

contrib-ы не считаются (и так подключаются, если надо), касательно green threads - их убрали вместе со сведением двух dynamic-space к одному (тащить потоки в VM требует такого разделения, чем-то аналогично user/kernel space; упростился GC, опять-таки). Смысла в «легких процессах» в вакууме нет - лёгкие-то они лёгкие, но как только начинается блокирующее IO всякий толк исчезает. Хороших процессов на уровне VM можно достичь только если изначально рассчитывать на такую модель - чистые функции, чтобы можно было параллелить не в терминах инструкций а в терминах редукций (pi/join calculi), отдельный поток на IO с соответствующими _асинхронными_ операциями (как в Erlang). Ничего подобного в CMUCL нет (и вряд ли будет в SBCL), поэтому появление нативных потоков на самом деле благо - это наиболее естественный путь для VM с блокирующим IO и непрозрачными функциями.

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

Никакого ast с собой ir не тащит.

А зачем? Проехали же уже AST, поработали с ним, дальше работают с последовательностью IR.

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

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

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

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

Печаль. И что, в том же GIMPLE SSA тоже восстанавливается?

Небось, считаешь, что CLR это стековая VM, да?

Не знаю, какой из тебя специалист по компиляторам, а телепат ты хреновый.

До тех же пор ты просто самоуверенный (без малейших на то оснований) неуч.

Я и не претендую :) И не жонглирую банальностями вроде «google: reflector», «современные компиляторы не делают оптимизаций на AST», «небось думаешь, что .NET - регистровая VM».

не смел бы

%)

>«современные компиляторы не делают оптимизаций на AST»

Это хреновые компиляторы.

IR1 в SBCL - суть AST, и на нем оптимизации делаются.

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

Я, кажется, знаю тебя. Ты не http://conscell.habrahabr.ru/ случайно? Вы похожи.

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

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

> А как это назвать?

не знаю, хотя бы AOT — на самом деле пересборка при первом запуске это худший случай, по-хорошему там должна быть пересборка при обновлении библиотек (типа post-inst скрипта)

Не надо тут маргинальщины. Ты компилятор мейнстримного языка покажи.

>>«современные компиляторы не делают оптимизаций на AST»

Это хреновые компиляторы.

IR1 в SBCL - суть AST, и на нем оптимизации делаются.

Какие именно? Кроме того, речь идет о «традиционных», статически типизированных языках.

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

Ыыыы... ты откуда вылезло, существо? И как насчет, реализованного на JVM Лиспа - он по уровню всё еще ниже Явы?

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

Развертывать проще, ынтерпрайзы это ценят

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

Собственно не там смотришь. Вот

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

IR1 в SBCL - суть AST

/Нудит/ ну вообще-то IR1 это flow-graph и намного сложнее (и бажнее) чем AST, оптимизации на AST делаются до IR1 и это фактически макро-трансформации примешанные к функциям (не defmacro и не define-compiler-macro, а define-source-transformation). На стадии IR1 можно определять драйверы deftransform/defoptimizer и def-ir1-translator они хороши тем, что уже имеют доступ к типам и к хитросплетениям flow-graph (пример, а ещё динамическая типизация, тем не менее типы на месте). Примерно в том же духе работает IR2 - есть драйверы define-vop, define-instruction и т.п. Короче весь процесс user-driven. От ридера и макрсов/макросов компиляции (что в стандарте) и так далее (в SBCL).

Какие именно?

Можете почитать на досуге - srctran.lisp.

Или вот - произвольные преобразования алгебраических выражений исходя из свойств операций (+/-) (*/%) - как вы это будете делать в LLVM? Понятно, что можно сделать соответствующий case в какой-либо из стадий компиляции (но хардкод), а вот к SSA это не сводится (даже в примитивных случаях - не удобно, не очевидно). Но также понятно что это простая функция AST -> AST, как разные математические пакеты (Maxima, Mathematica) делают такие упрощения, так и компилятор может это делать в compile-time просто над выражениями (expression т.е.) нужно только чтобы была возможность user-driven превращения - изменяемая табличка пользовательских функций (AST -> AST) которые будут применяться (пользователь, в смысле использующий API компилятора для расширения его свойств). Как частный случай - constant folding.

Вброшу ка я еще немного.

Чистая функциональщина вроде хаскеля может частично оптимизироваться на уровне ast. Механизм — что-то вроде системы переписывания термов, основанной на унификации второго порядка.

Как обстоят дела на практике не интересовался, не мой профиль. Однако читал пару статей на эту тему.

Правда если лисп не интерпрайз, то хаскель — не ынтерпрайз вдвойне. А посколькудолжна никакого ынтерпрайза кроме Си(++), жабы, бейсика и кобола нету вообще, то спор теряет всякую содержательность и превращается в веселое кидание какашками.

Я люблю тебя, ЛОР

> Без диского кеша имеет место небольшой лаг при первом обращении к коду. Ну представь, что он есть у JVM, и что теперь?

Ты совсем не понимаешь сущность JIT. У тебя три попытки указать ошибку (на уровне 2х2=5) в том твоём утверждении, которое я сейчас процитировал. Предыдущий оратор с первого раза не смог указать, со второго полез в бутылку. Посмотрим, как ты выдержишь.

> Тем не менее, давайте учтем, что Java - язык довольно низкоуровневый, и, притом, статически типизированный.

Ну, я тут немного запутал всех, наверное. Тормоза SBCL, с которыми я столкнулся на shootout, были связаны с тем, что fixnum в SBCL там имеет несколько меньше, чем 32 разряда. Поэтому, там,где Java может считать быстро, лисп сливает из-за перехода к bignum. Не факт, что соотношение сил сохранится, если к SBCL прикрутить 32-разрядную арифметику. Хотя не знаю, может там есть и 64-разрядные бенчмарки, где лисп тоже сливает...

Самая показательная картинка, ИМХО, вот эта - http://shootout.alioth.debian.org/u64q/code-used-time-used-shapes.php. Учитывая, что будущее за 64-кой и массивным SMP.

Посмотрим, как ты выдержишь.

Нахер ты мне нужен. У меня жаба после профилирования работает как надо и держит приличную нагрузку. Никаких проблем с JIT нету (по крайнем в конкретно моем проекте). Есть в компании проект с производительностью, аналогичной производительности решения на Си. Никаких проблем с JIT в плане производительности тоже нет. С gc так да, есть. Но ни как ни с JIT.

Говорят, что при исполнении уже скомпилированного кода с использованием MOP может запускать компилятор - можно ли это считать формой JIT компиляции?

Вот, можно заценить «небольшую задержку при первом запуске». Open Office Calc при первом запуске заставил меня ждать ни много, ни мало - 25 секунд. При втором запуске загружается секунды за две. Microsoft Excel 2000 загружается за две секунды уже при первом запуске.

Возможности обеих программ примерно одинаковы, разница - в том, что в Open Office часть кода написана на Java. Можно сделать осторожный вывод: JIT украл у меня 23 секунды и это - как раз тот самый «едва заметный» лаг, о котором тут поют песни некоторые энтузиасты этой технологии. Мне не нравятся такие программы.

> Нахер ты мне нужен
Ну вот, и ты тоже слился. Понимаешь, мы тут не цвет и вкус обсуждаем. Программирование - оно является вещью объективной. Ты сказал херню. Если тебе удобнее меня послать и продолжать себя, некомпетентного, уважать, то тебя можно только пожалеть, но я тебя жалеть не буду. Я тебя дематериализую. Исчезни.

> Говорят, что при исполнении уже скомпилированного кода с использованием MOP может запускать компилятор - можно ли это считать формой JIT компиляции?

Ну, это - вопрос терминологии, если захотеть, то можно считать. Хотя я бы не стал.

Кстати, в MS SQL Server тоже есть JIT, хранимая процедура там компилируется при первом обращении.

Кусок с википедии:

For instance, most Common Lisp systems have a compile function which can compile new functions created during the run. This provides many of the advantages of JIT, but the programmer, rather than the runtime, is in control of what parts of the code are compiled. This can also compile dynamically generated code, which can, in many scenarios, provide substantial performance advantages over statically compiled code, as well as over most JIT systems.

Т.е. всё-таки JIT. Тем не менее нужно различать различные проявления JIT (может даже совсем различные):

1) Ручной доступ к компилятору и возможность построить код как в цитате выше. Это скорее такая техника - иногда, к примеру в случае превращения регулярного выражения в *код* конечного автомата который может быть скомпилирован, это даёт выигрыш в производительности - трансляция в ДКА это принципиальный подход, поэтому всегда лучше потратить время на run-time компиляцию строки в код ДКА и затем время на работу #'compile. В итоге это даст быстрый нативный матчер. От компилятора требуется всего лишь расшарить свои функции, а от рантайма уметь динамически выделять память для всех базовых типов (этого рантайма). Примерно такое поведение можно наблюдать в SBCL или в HiPe.

2) Другое дело когда изначальный байт-код (как компактное представление AST без потерь или как что-то производное с потерями (возможно с большими)) превращают в нативный код. Не думаю что такой JIT может быть причиной тотальных задержек - его ведь можно делать постепенно и параллельно, по мере обращения (вообще, нет смысла компилировать всё - как раз-таки нужны только те процедуры которые начали задействоваться, потом от условной main можно построить дерево очерёдности компиляции). Вряд ли по поведению сложных офисных пакетов можно о чём-то судить (и потом - неизвестно, что там внутри Экзеля :) Т.е. JIT как возможность интерпретируемым языкам приблизится к компилруемым (но не догнать!). Что касается генерации JIT-ом каких-то особых инстрыкций под текущую архитектуру - компилятор ведь один и API у него одно и тоже, поэтому статически компилируемая программа тоже может быть скомпилирована именно под такую архитектуру. Разве что JIT даёт преимущество дистрибуции тут, это ещё один плюс.

3) Некие «динамические оптимизации». Допустим, есть статический компилятор нативного кода и другой такой же, но использующий JIT не в смысле техники (1) а в смысле динамической (на лету) оптимизации. Тут трудно что-то сказать - предположить что умный оптимизатор работает параллельно и как-то подстраивает нативный код в соответсвии с харрактером его текущего использования, это довольно смело. Только если предсказывать gcc-like likely/unlikey. А всё остальное это уже суперкомпиляция, вообще академическая область.

суперкомпиляция

Типа, кто-то с завидным постоянством вызывает foo(5) и получает 10, и мы знаем что foo читая и долго работает, поэтому мы принимаем foo 5 = 10, мемоизируем, но с учётом того что знаем, что на foo(5) есть спрос, поэтому «повышаем» на этом участке «предложение». Аналогично более сложные эвристики - но это нужно очень умные принципы закладывать, в частности компилятору придётся возится с информацией об оценках сложности (то чем обычно люди занимаются, которые алгоритмы профилируют).

Программирование - оно является вещью объективной.

А вот и нет. Программирование не удалось «рационализировать». Все учения по програмной инженерии провалились с треском.

Твои ГСМ домыслы лишь тому подтверждение.

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

Open Office Calc написан на C++.

> Т.е. всё-таки JIT
В лиспе всегда всё можно скомпилировать и сохранить в виде фаслов или образа, что, как правило, и делается. Т.е. это - не JIT, а, я бы сказал RIT, Really in time.

Open Office Calc написан на C++

В Википедии написано, что OOo написан на C++ и Java. Посмотрел, что Calc открывает при запуске - файлов jar и class вроде нету. Хотя существует директория classes и в ней находится 9 мб jar-файлов.

> Аналогично более сложные эвристики - но это нужно очень умные принципы закладывать
И это уже не будет быстро компилироваться.

>Возможности обеих программ примерно одинаковы, разница - в том, что в Open Office часть кода написана на Java. Можно сделать осторожный вывод

Прежде чем делать выводы, запусти OOo без Явы. Увидишь, что разница в скорости незаметна

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

По всей видимости, каждый останется при своём мнении, как это обычно и бывает. Думаю, что я разобрался для себя с вопросом, спасибо за комментарии.

Мои выводы таковы: - существуют области, в которых JIT действительно имеет смысл из-за того, что она работает на основе профилирования кода, я узнал новые способы оптимизации (предсказание переходов на основе статистики). Это касается программ, которые редко запускаются и долго работают (сервера). Однако, и в этих областях медленный старт приложения может вызвать потери времени разработчика на этапе отладки. Также, медленный старт сервера - это тоже плохо, поскольку желательна работа сервера в режиме 24х7 с минимальными перерывами. Статическую программу можно собрать не на серверной машине (с использованием кросс-компиляции, если отличается архитектура) и после запуска она сразу будет работать со своей нормальной скоростью. Запуская сервер с JIT, мы, во-первых, переносим затраты компиляции на сервер, во-вторых, не можем сразу полагаться на его быстродействие, а чтобы он «разогрелся», мы должны его специально «пнуть», подав на него запросы, чтобы вызвать срабатывание компилятора. «Разогнавшись», сервер будет работать гораздо быстрее, но на клиентской стороне мы будем вынуждены ставить больший таймаут ожидания только из-за того, что существуют перезапуски и период разогрева. В общем, это не выглядит надёжным там, где есть хоть какие-то требования к времени отклика. Т.е., и в серверных системах использование JIT вызывает у меня сомнения.

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

Для приложений, которые запускаются часто и не на долго, JIT вредна. Здесь мы имеем то, о чём я писал сразу, т.е. развод на бабло.

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

Также надо отметить, что у человека в голове тоже есть некий аналог JIT. Он работает во время тренировок, будь то заучивание таблицы умножения, обучение игре на музыкальном инструменте или танцам. Человек сначала интерпретирует алгоритмы, а потом (спустя время), когда алгоритм уже ясен и проработан в разных ситуациях, происходит скачкообразное или постепенное улучшение результатов, при этом снижается степень осознания человеком того, что он делает (переход на «автопилот») и увеличивается скорость.

>Для приложений, которые запускаются часто и не на долго, JIT вредна.

Да ты просто К.О. В HotSpot на начальной стадии запуска приложений в клиентском режиме применяется интерпретация

медленный старт сервера - это тоже плохо, поскольку желательна работа сервера в режиме 24х7 с минимальными перерывами

при нормальной работе сервера не бывает перерывов

Также надо отметить, что у человека в голове тоже есть некий аналог JIT.

вдоль

Да, и кстати, серверная Ява весьма быстра на шутауте и обгоняет, к примеру, статически компилируемый FreePascal. Т.е., здесь мы видим пример условий, при которых JIT оправдывается. Правда, в реальных условиях затраты памяти можно пересчитать в быстродействие. Когда памяти недостаточно (а её почти всегда недостаточно), скорость работы компьютера ограничивается скоростью свопа памяти на жёсткий диск. Во всяком случае, JIT в этих бенчмарках умеет правильно купить скорость, заплатив памятью и его нельзя назвать совсем уж порочной технологией. Вопрос лишь в том, правомерно ли его применение во всех случаях (например, для IDE или офисных программ). Нет, я не буду мерять время запуска ОО с Явой и без, в общем-то, мне это уже не нужно.

опрос лишь в том, правомерно ли его применение во всех случаях (например, для IDE или офисных программ).

Еще раз образаю твое внимание, что пользователь IDE - это один человек. И он не работает со скоростью 100 кликов мышкой в секунду. По сути это смешная нагрузка. Сколько работаю с эклиспом - все гладко, совершенно не заметно, что он греется. Жава в клиентском режиме тоже имеет свои эвристики. Код начинает выполняться немедленно, без задержек на JIT, но в режиме интепретации. Компиляция идет в фоновом режиме в отдельном треде. Что бы отменить такое поведение и вызвать лаг, нужно запустить JVM с параметром -Xbatch. Хотя если при старте приложения сразу фиганет какая-нибудь тяжелая арифметика, то возможно торомоза будут, т.к. интерпретация сильно сольет, но мне пока такие приложения не попадались.

Серверная Java это, как раз, фактически, AOT, а не JIT.

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

Еще раз - плюс JIT'а это только, и только, портабельность. А упомянутые предсказания ветвлений успешно делаются самим процессором, для нейтив кода; какая-то перекомпиляция из байткода, на основе статистики, в этом плане - вещь совершенно лишняя, и даже вредная(добавляет тормозов и сбивает кэши процессора совершенно безо всякой полезности).

Ну и, еще раз - некорректно сравнивать «Java с JIT» и «CL(или любой другой подобный язык) без JIT». Надо сравнивать SBCL и любую реализацию любого динамического языка подобного уровня, с JIT - V8, и т.п.(да хоть clisp + gnu lighting) И в этом случае выходит так, что JIT «быстр» только в сравнении с тупой интерпретацией, но не с оптимизирующим компилятором.