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

> Ну и, еще раз - некорректно сравнивать «Java с JIT» и «CL(или любой другой подобный язык) без JIT»
Я согласен. Но практика такова, что JIT распространяется, как зараза.
И происходит зомбирование как раз в том месте, где происходит подмена сравнения статическая компиляция<->JIT на сравнение интерпретация<->JIT. Это - очень общий паттерн манипулирования, который применяется от политики до медицины. В наиболее общем виде его можно было бы обозначить так:

Давайте сделаем клиенту намного хуже, чем могли бы сделать. А потом сделаем ему чуть лучше, чем сделали сначала. Клиент скажет нам спасибо.

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

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

Что имеем в итоге? Ещё одна технология замедления работы компьютера находит всё более широкое внедрение. Это-то и плохо, поскольку в итоге это выливается в софт низкого качества. В тормозные телефоны, которые минуту включаются, в тормозные программы, которые долго запускаются. Общий итог: мы снова и снова платим деньги за компьютеры, которые, по сути, делают всё то же самое, что могли делать и старые компьютеры.

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

Тред не читал.

не все языки программирования вот так легко взять и скомпилить. JIT для многих это ускорение мест в которых можно ускорить. Ну в случае с жабой мне кажется там можно было все компелять )

Нда, и кстати, разгадываю ошибку, которую допустили два человека (один из них добавлен в игнор-лист).

Эти два человека утверждали, что «интерпретация будет до первого обращения к коду, после чего он будет скомпилирован».

Я не думаю, что эти люди - идиоты. Скорее тут налицо маркетроидное приукрашивание ситуации, которое эти люди вовремя не пресекли, когда изучали JIT и поверили в него. Такое, с позволения сказать, двоемыслие (Оруэлл - всё же гений, и писал он вовсе не про СССР, как это утверждают некоторые преподаватели). Я не читал почти ничего про JIT дальше Википедии, но и мне известно, что компиляция обычно происходит не после _первого_ обращения к коду, а только после _энного_ обращения к коду, где эн определяется настройками JIT. Однако эти два человека предпочли послать меня, а не найти багу в своих словах (и, следовательно, в своих знаниях).

Что вытекает из этой баги? Представим себе программу на 100Мб байт-кода. Пусть вся программа представляет из себя один огромный цикл, который исполняется эн+1 раз. Что мы получим? Получим мы вот такую http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=javaxint производительность в течение всей работы программы. Под занавес запустится компилятор и будет компилировать 100Мб. Сколько это будет стоить? Предполагаю, что это займёт ещё десятки-сотни секунд, просто исходя из опыта работы с разными компиляторами. Потом будет одно быстрое исполнение цикла, а потом программа успешно закроется.

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

На этом, в общем-то, пора заканчивать. Дальнейшие рассуждения над темой предоставляются читателю.

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

Простота грамматики никак не связана с семантической близостью к целевой платформе. Вот scheme еще проще и «тупее» чем жава и Си. Но компилиовать в нейтив еще сложнее. В жаве довольно много наворотов вроде боксинга/анбоксинга и «жирных» структур данных. Массивы используются гораздо реже, чем списки. В Си ситуация обратная.

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

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

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

Тут уже давали ссылки на shootout.alioth.debian.or где видно, что Java с ее JIT обгоняет оптимизирующие компиляторы Free Pascal, OCaml, SBCL, Intetl Fortran. Есть над чем задуматься.

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

Единственный известный мне юзкейс, где JIT эпически сливает - это real-time системы. Тут уж извините.

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

Да, в таком случае JIT сольет и очень сильно. Но увы, такого кода в жизни не водится.

В догонку еще один полезный юзкейс JIT. Тут все говорят про оптимизирующие компиляторы, как буд-то все эти оптимизации даются бесплатно. Сишные проги компиляются долго. С++-е просто адски долго. Java-же к примеру собирается очень быстро. Быстрее цикл поправил-собрал-попробовал.

me хотеть интепретатор жавы для разработки :) Так было бы еще быстрее. Хотя я уже посматриваю на Common Lisp (SBCl + Slime). Там вроде с этим получше.

sbcl тоже сначала компилит потом исполняет.

>Простота грамматики никак не связана с семантической близостью к целевой платформе. Вот scheme еще проще и «тупее» чем жава и Си.
Грамматика Java как раз сложная. А семантика - тупая и простая.
В отличие от Scheme, где ситуация обратная(Scheme как раз относительно сложный язык для компиляции - там полностью динамическая типизация, плюс continuations и т.п.)

В жаве довольно много наворотов вроде боксинга/анбоксинга и «жирных» структур данных.

И где в этом сложности?

В Си ситуация обратная.

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

Все они сдохи впоследствии за ненадобностью.

Скорее под давлением маркетологов и «основной» реализации.

Еще одним плюсом JIT можно назвать более рациональное использование многоядерных систем.

Совершенно не вижу как. Ортогональные вещи.

Помните что там писал Пол Грэм про языки будущего? JIT - технология будущего.

Бредятина.

что Java с ее JIT обгоняет оптимизирующие компиляторы Free Pascal, OCaml, SBCL, Intetl Fortran. Есть над чем задуматься.

Да, надо думать, а не пороть херню.
FPC - говно, разрабатываемое энтузиастами на коленке. OCaml - высокоуровневый функциональный язык, и плюс, на разработку его компиляторов потрачено гораздо меньше бабла, чем на Жабу. Фортран оптимизируется в основном на числодробильню, а не на высокоуровневые какие-то штуки, плюс там невероятно тупой код для него, на шутауте, не оптимизированный.

Про SBCL, еще раз повторю: CL - невероятно динамичный, высокоуровневый(намного выше уровнем, чем Java) язык, с динамической типизацией. Его очень сложно компилировать в эффективный машкод. Сравнение с Java неуместно. Вот когда будет JIT для языка подобного уровня, который бы обгонял SBCL(и в этом я сильно сомневаюсь) - тогда и можно будет говорить о сравнении. Пока же - что JS V8, что LuaJIT, что clisp + gnu lightning - и рядом с SBCL не валялись(даже если декларации типов убрать в коде на CL - я лично сравнивал).

Ну там же все вроде инкрементально.

Скорее под давлением маркетологов и «основной» реализации.

Это рынок детка. Тут нет место дрочероам на миллесекунды. Как тут уже писали, для JavaME технология AOT прижилась - там оно востребовано. И маркетологии и прочие заговорщики, как видишь, не помешали. А для обычной жавы слишком мало юзкейсов AOT компиляции. Если бы это было полезно, то на такую фичу был бы спрос и она была.

Вот когда будет JIT для языка подобного уровня, который бы обгонял SBCL

См Scala. Он менее динамичный, но и CL без декларации типов как черепаха.

даже если декларации типов убрать в коде на CL - я лично сравнивал

Не верю.

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

А как его посчитать, эээ?? Вот есть допустим два-три AOT компилятора явы: Excelsior Jet, gcj, OpenJDK/llvm или нечто из VMKit. Разные приложения, разные компиляторы, разные параметры компиляторов (хотя бы серверная ява/клиентская) — дадут разные цифры.
И интересно в процентах всё-таки, да. Если считать sun-jdk 1.6 за 100%.

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

Нельзя делать такие суждения.

> Вот scheme еще проще и «тупее» чем жава и Си. Но компилиовать в нейтив еще сложнее.

я несогласен. Погугли в раёне сайта Gambit scheme, найдёшь презентацию «как написать компилятор схемы за 90 минут». Не очень эффективный, но быстро и понятно.
Теперь, что есть аналогичного для Си компиляторов? Один парсер/лексер Си — это мозг вывихнуть можно.
Среди Си компиляторов аналогичный по простоте разве что компилятор Яна Пийуматры (Ian Piumatra) через PEG. Но от тоже компилирует код в S-выражениях, т.е. их надо ещё распарсить. tcc Фабриса Белларда (2), Small C или Pawn — 3.

Схему в целом проще компилировать чем Си.

В жаве довольно много наворотов вроде боксинга/анбоксинга и «жирных» структур данных. Массивы используются гораздо реже, чем списки. В Си ситуация обратная.

и что? Это фишки скорее рантайма явы, аналогичные libc / c runtime library в Cи. Как это относится к сложности конпелятора?

> Эти два человека утверждали, что «интерпретация будет до первого обращения к коду, после чего он будет скомпилирован».

Я не думаю, что эти люди - идиоты. Скорее тут налицо маркетроидное приукрашивание ситуации, которое эти люди вовремя не пресекли, когда изучали JIT и поверили в него. Такое, с позволения сказать, двоемыслие (Оруэлл - всё же гений, и писал он вовсе не про СССР, как это утверждают некоторые преподаватели). Я не читал почти ничего про JIT дальше Википедии, но и мне известно, что компиляция обычно происходит не после _первого_ обращения к коду, а только после _энного_ обращения к коду, где эн определяется настройками JIT.

Ересь и ахинея. Это не JIT «компилирует после первого обращения». Это скорее описан JTL (Just Too Late) из Etoile/Smalltalk через LLVM — интерпретировать и скомпилировать выполненное, вдруг ещё понадобится. JIT компилирует «до» обращения.

А толку от такой компиляции? Мы говорим про эффективную компиляцию. А вот это хрень полноя:

BEGIN_CLOSURE(1,0); END_CLOSURE(1,0);
PUSH(LOCAL(0/*r.5*/)); GLOBAL(0/*square*/) = TOS();
PUSH(GLOBAL(0/*square*/));
BEGIN_CLOSURE(2,0); END_CLOSURE(2,0);
PUSH(INT2OBJ(5));
BEGIN_JUMP(3); PUSH(LOCAL(2)); PUSH(LOCAL(3)); PUSH(LOCAL(4)); END_JU

и чем эта хрень тебе не нравится?? судя по push — обычная стековая вирт. машина.
если ты заводишь речь об *эффективной* компиляции, дай своё понимание эффективности.
например: FPC (FreePascal) или tcc (C) позволяет компилировать в эффективный код.
use case: берём тупой простой код, которому не потребуются хитрые оптимизации (функции API с 2-3 параметрами, и т.п). Конпелируем хоть тупо с бумажкой и ручкой — и отконпелировано будет эффективно.
контрпример: берём API из реальной жизни, которое не удастся распихать по регистрам в x86.

например, можно утверждать что регистровый байт-код эффективнее стекового (опять-таки, для какого именно API): есть сравнение в papers к Lua, 4.0 — стековый, 5.0+ — регистровый. соглашение вызова fastreg эффективнее stdcall / сdecl => регистровый код эффективнее. правда, в реальной архитектуре ещё вопрос, и эффективность размещения по вирт. регистров по регистрам физическим — вопрос эффективности. поэтому SSA из LLVM «эффективнее» вручную раскиданного по регистрам кода, т.к. можно менять алгоритм размещения, отображения виртуальных регистров на реальные (раскраской графа, или сейчас модно через E-PEG->CFG доказательством теорем — начальные результаты не сильно хуже, а оптимизаций можно больше навесить).

выдай своё определение эффективности, почему приведённый код стековой абстрактной машины — неэффективен, а байт-код стековой JVM машины — эффективнее. на каких операциях?

вот конпелятор by Ian Piumarta например: http://piumarta.com/S3-2010/ рядом лежат исходники (self bootstrapped from C, peg/leg) и pdf.

Discussion The generated code runs at 75% the speed of the same program written in C and compiled with typical optimisation (gcc-4.3 -O2) on Intel Core and Core2 processors. The executable code is 1.8 times larger than the C version. Several peephole optimisations are possible between the middle- and back-end. Their definitions are obvious (from inspection of the generated abstract code for frequently-occurring sequences) and their impact on performance easily measurable. Removing the occurrences of addl $4, %ebx subl $4, %ebx increases performance to 80% and reduces size to 1.55 times optimised C. Making a special case of comparison with a literal integer followed by a conditional branch (to give movl 0(%esi), %eax cmpl $2, %eax jge L1 just before L1) increases performance to 96% and reduces size to 1.48 of C. Simplicity and clarity, rather than performance, are the primary goal—to make the successive transformation of source to binary understandable at every stage. Less than 100 lines of PEG code and about 20 lines of auxiliary function code are needed to compile the example program presented here. In the author’s opinion, any competent CS student should be able to understand the compilation chain in a matter of hours and add the two optimisations described above with less than one day of work. We consider this an excellent result to achieve 96% the speed of optimised C (for simple numerical programs), which is sufficiently fast for many purposes.

вопрос на засыпку : это — эффективный конпелятор или не? почему? (если закрыть глаза на скорость конпеляции этим конпелятором, а измерять характеристики только собранного им кода)

я так думаю, что для достаточно тупых и тривиальных примеров, 96% — это выдающиеся результаты. главное, что этот конпелятор гораздо проще и понятнее gcc :)) сравни, к примеру, исходники pcc tcc, этого конпелятора, и чего-нибудь поынтерпразнее вроде gcc или clang.

>Один парсер/лексер Си — это мозг вывихнуть можно.

Только седня читал, что написать примитивный компилятор Си - это как два пальца, а об OCaml мозг вывихнуть можно :)

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

к примеру, вот что пишут в бложике Etoile: http://etoileos.com/news/
про производительность ObjectiveC vs. Smalltalk http://etoileos.com/news/archive/2010/04/27/2303/

а вот, что про Objective C runtime, новый (libobjc2 заместо GNU): http://etoileos.com/news/archive/2009/09/10/1744/

ему тоже не нравиццо столлманов код про objc рантайм (или там костыли ещё со времён poc торчат?), но он это «не нравиццо» сумел разумно переработать: написал свой рантайм libobjc2, померял, и по результатам измерений сказал: мой рантайм эффективнее, а столман фигню спорол.

>С++-е просто адски долго

Use Clang, Luke

int foobar (xyzzy a, snafu b);
1. typedef (*foobar)(xyzzu,snafu) ; // декларация переменной указателя на функцию
2. декларация функции.
3. #define foobar (blabla[10])

утверждение, что это — хрень полная — не объективно. даже не интерсубъективно.

Ну а толку от такой компиляции? Это же байт-код по сути, а не машинный код (gcc из него сделает машинный код, но это уже не считается). CPython вон тоже в байт код компилит, и все равно медленный.

> А как его посчитать, эээ?? Вот есть допустим два-три AOT компилятора > явы: Excelsior Jet, gcj, OpenJDK/llvm или нечто из VMKit. Разные

приложения, разные компиляторы, разные параметры компиляторов (хотя

бы серверная ява/клиентская) — дадут разные цифры

Спасибо, во-первых, за ссылки на эти компиляторы. Предыдущие ораторы то говорили, что таких компиляторов нет, то, что они есть, не называя имён. Посчитать просто: взять разные приложения и пробовать.

Чёрт, написал большой пост и он куда-то делся. Коротко говоря. Ты не знаешь матчасть. JIT - термин многозначный (а этого не знал я). Исконное значение термина - компиляция при первом обращении. HotSpot - основная и, наверное, наилучшая JVM, компилирует так, как я сказал. И это называется «JIT в широком смысле слова» и именно об этом я и говорил с самого начала. Непонимание возникло из-за искусственно введённой маркетологами многозначности термина и из-за того, что некоторые (включая тебя) не читают дальше первого абзаца. Тут можно ещё писать много про маркетроидную магию, но я не буду повторять то, что пропало.

http://www.ibm.com/developerworks/ru/library/j-jtp12214/

Ну а толку от такой компиляции? Это же байт-код по сути, а не машинный код (gcc из него сделает машинный код, но это уже не считается).

то есть, тебе не нравится искусственный байткод, а нравится нативный бинарник? ты будешь смеяться, но этот *.o из gcc — точно такой же байткод, только от другой машины (ближе к нативному коду, да). потому что ноги у C растут из BCPL, а *.o — из O-code из O-code машины во время перехода от BCPL к C и от INTCODE/O-code интерпретатор/компилятор O-code встроился в компилятор GCC *.o файлов :)) можно считать GCC таким AOT компилятором *.o кода. А виртуальной машиной — загрузчик ELF файлов вкупе с динамическим линкером ldd, который обеспечивает релокации. а споет над ldd --- недокументированной фичей, выполняющей сильно unsafe код :)

медленный не потому что байткод. Бывают быстрые байткоды (O-code или Zork VM или Oberon-2 и slim binaries by Michael Franz see also and here (это тоже байткод, но более эффективный. При загрузке загрузчиком компилируется, то есть, фактически как ngen в .NET).

я что хочу сказать. Не любой байткод медленный, и если можно говорить о эффективном/неэффтивном компиляторе, можно говорить и о эффективном/неэффективном байткоде. К тому же, сильно зависит от того, как код используется. Вон в Etoile Smalltalk замеряли тесты, и по тестам код, выполняющийся под интерпретатором выполнялся быстрее откомпилированного. Потому что его надо раз выполнить и выкинуть, а компилированный надо ещё сгенерировать, загрузить, обеспечить релокации или сразу генерить более медленный PIC код, и т.п.

Ну то есть, точно так же как про эффективность байткода, можно говорить и про эффективность модели компиляции (AOT, JIT, JTL Just Too Late)

тесты, в которых JTL оказался быстрее JIT

тесты, по которым компилятор смоллтока через LLVM оказался медленнее интерпретатора

хотя для хелловорда с фибоначчи, и для довольно сырого рантайма такие тесты мало что показывают. Вот например, тут смоллток с оптимизациями оказался быстрее Objective C без оптимизаций. И да, разница смоллток/objc небольшая, в рантайме, а разница c/objc существеннее, в 3 раза.

И это называется «JIT в широком смысле слова» и именно об этом я и говорил с самого начала. Непонимание возникло из-за искусственно введённой маркетологами многозначности термина и

непонимание от того, что разные реализации JIT дадут разные результаты. Вполне возможно, что JIT в LLVM более сырой, чем JIT в HotSpot. Поэтому сравнивается не JIT вообще против AOT/JTL вообще, а оптимизации HotSpot JIT против других реализаций JIT. Да, HotSpot JIT более оптимизирован под Java runtime. Ну и что? для другого языка соотношение может быть другим. Изменится сценарий тестирования, и надо будет опять компилировать методы в JIT HotSpot, но не надо будет в JTL.

> непонимание от того, что разные реализации JIT дадут разные результаты
И ещё много непонимания от многоликости слова «anonymous». Например, неясно, ты - тот же анонимус, который только что не знал ничего про JIT дальше первого абзаца и теперь резко перекрасился, или ты - совсем другой человек.

> Посчитать просто: взять разные приложения и пробовать.

я не очень понимаю, что такой тест будет показывать. Вот, например, Eclipse можно собрать gcj, но с classpath/harmony jdk будут глюки, скорее всего. Так что, тест не совсем адекватный.
Но допустим, берём OpenJDK с LLVM компилятором. И собираем тот же Eclipse через sun-jdk-1.6 или компилируем весь эклипс через LLVM. Что запускаем, что пробуем?
Загружаться он будет быстрее, скорее всего. Но то, что динамические характеристики какие-то будут лучше, очень под вопросом (кстати, за статью с dW спасибо). Потому что, допустим пользователь1 со сценарием: запускает/открывает проект с хелловордом/закрывает IDE, пользователь2: запустил, обновил все плагины, открыл проект объёма исходников ядра или больше. Т.е., сценарий какой-то тестовый должен быть единый и адекватный.


а то у меня был такой «типа тест»: собрал helloworld окошко с кнопкой на SWT, запустил под sun-jdk; собрал gcj, запустил; взял язык D и DWT оттуда (порт SWT), собрал, запустил. Получилось 15М кода, в вариантах gcj/dmd (статически собрано). Понятно, что пока эти 15М будут грузиться, jre уже запустится и закроется, т.е., JRE тут быстрее будет, несмотря на то что байткод, а не «нативный код» :))

С++-е просто адски долго

Use Clang, Luke

лучше не Clang. Лучше какой-нибудь ooc. Под него и симпатичные llvm биндинги есть, и модель компиляции симпатичная: транслируется в Си, прозрачно линкуется с си либами, собирается вашим любимым (gcc/clang/tcc/icc/whatever) конпелятором. Потому что синтаксис имеет значение. Кстати, любопытно было бы если бы конпелятор ooc умел транслировать не только через С, но и напрямую через llvm. Есть ли разница от си компилятора.

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

Ответ не найден. Логика не обнаружена.

> Т.е., сценарий какой-то тестовый должен быть единый и адекватный
В общем, это - тема для очередного диссера. Но не для моего диссера :-)

Ну что ты тут разнервничался? Ты задолбал писать и так абсолютно ясные для все вещи.

> Но практика такова, что JIT распространяется, как зараза.

И происходит зомбирование как раз в том месте, где происходит подмена сравнения статическая компиляция<->JIT на сравнение интерпретация<->JIT. Это - очень общий паттерн манипулирования,

тема манипулирования не раскрыта. Какое сравнение подменяется каким, и зачем? Какая в этом «социальная» необходимость? Кто кого дурит и зачем? (а если сами себя?)
Скандалы, интриги, расследования.

Нам не дают быстрых компиляторов заместо медленных интерпретаторов, выдавая паллиатив-затычку JIT?

Вот есть языки, которые компилировать просто, а есть языки, которые компилировать сложно. С другой стороны, есть языки, эффективные, а есть не очень эффективные. То есть, если есть «эффективность компилятора», её можно понимать как 1) скорость выполнения компиляции 2)скорость выполнения накомпилированной программы.
Сейчас, большинство принимает в расчёт 2) и игнорирует 1). В итоге имеем C++ и вообще языки с Си синтаксисом и долгое время конпеляции того же буста. Но, мыши плачут, колются, но продолжают конпелировать, потому что 2) максимальна. При этом, тотальное игнорирование 1) приводит к тому, что услышав о continuos integration, возникает такое же тотальное непонимание, как это так, у нас ведь билды по часу делаются.
При выборе конпелятора конкретного, заданного языка происходит trade-off: какая 1) максимальна при прочих максимальных 2) и остальных плюшках.

Точно так же как с конпеляторами, есть личные персональные особенности программистов. Есть парадигмы программирования, концепции и подходы, эффективные и не очень. То есть, «эффективность программиста» можно понимать как 1) скорость его способности решать задачу при прочих заданных условиях (плюшки, языки, конпеляторы) 2)эффективность выработанного им решения.

Меня терзает сомнениями тот факт, что с конпеляторами работает выбор по приоритетам: 2-1, тогда как с программистами 1-2. Как так случилось, и почему?

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

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

Продолжение в следующем выпуске. Скандалы, интриги, расследования.
//капча Histere

Вот есть shootout. Сами по себе сравнения не очень полезны, т.к. сравниваются хелловорды. Но есть качественная сводная картинка. Которая тоже не очень полезна, ибо все варианты решений написаны разными людьми, в разных парадигмах и языках. То есть, это разные решения. Теперь положим, мы берём один какой-то язык за основание, baseline (положим, C). И сравниваем кодогенераторы разных компиляторов, переводя (транслируя) решения на языке С в эти конкретные языки. То есть, пишем на лиспе как на Си, на хаскеле как на си через монады и стрелки (вроде IO-монады), и т.п. Повторяем сводную картинку, для одного конкретного си-решения, оттранслированного в другие языки . Что она показывает? 1) насколько хорош кодогенератор в конкретном конпеляторе конкретного языка, по сравнению с С конпеляторами 2)насколько хорошо язык реализует «парадигму С».

Или, наоборот, возьмём за baseline некоторое «абстрактно-оптимальное правильное» для каждого языка решение. Затем, оттранслируем этот язык в Си, и отконпелируем С конпелятором. Насколько хорошо ложится это решение на язык С.

С здесь просто для примера выбран. Но по визуально картинке по первой ссылке, например, можно сделать вывод, что взяв Ruby и gcc c (самую первую и самую последнюю), видно, что в языках сделан выбор разных trade-off'ов, т.е., решения на этих языках отличаются скорее всего качественно.

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

> Какое сравнение подменяется каким,
По-моему, я это написал достаточно однозначно.

Какая в этом «социальная» необходимость?

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

При выборе конпелятора конкретного, заданного языка происходит trade-off

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

Например,

Delphi, который будучи достаточно выразительным и достаточно быстрым, компилирует раз в 50 быстрее С++. Т.е., это, на мой взгляд, оптимальный статический язык, там, где Питон не пройдёт по производительности, но выжимать всё возможности из процессора ещё нет необходимости. Также есть альтернативные (более быстрые) компиляторы C.
С++ - это вообще неудачная технология, её не стоит приводить в качестве опоры в каком-то выборе.

Common Lisp, где есть AOT, интерпретация, continuous integration, всё это настраивается на уровне makefile или на уровне программирования и находится под полным контролем разработчика, без всякого JIT. Да, CL несколько медленнее Жабы (по бенчмаркам), но давайте сравним популярность CL и Жабы и, соответственно, затраты усилий на оптимизацию за последние 10 лет. Безусловно, все те фишки, которые использует HotSpot на сервере, могут быть воплощены и в рамках CL. А также есть гибкость, в CL можно на лету не только ДОопределить программу, но и очень многое в ней ПЕРЕопределить.

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

У каждой из этих технологий (Delphi и Common Lisp) есть недостатки, но это недостатки другого рода, которые можно вынести за скобки данного компромисса.

> можно сделать вывод, что взяв Ruby
Можно сделать вывод, что Ruby - это Г. Поскольку, кроме синтаксиса, он ничем не лучше лиспа, который занимает довольно высокую ступеньку.

> что в языках сделан выбор разных trade-off'ов
Или что языки просто сделаны хорошо или плохо. Т.е., если в каком-то языке что-то плохо, то это может быть не trade-off, а просто flaw. Просто одно получилось плохо, а ничего хорошего вместо него не появилось. Простите мой Нижегородский. Большинство современных технологий - это flaw. Но чтобы это понять, нужно изучить CL. Например, Питон, будучи тормозным и неускоряемым, в то же время не допускает нормальную интерактивную разработку. CL, будучи ускоряемым, допуская строгую типизацию, при этом допускает и интерактивную разработку. Видим: дизайн Питона - это flaw, мы потеряли скорость, но не получили взамен ничего. Он выехал только за счёт жизненной силы молодого организма, за счёт простоты базовых конструкций и пологости кривой обучения, чем CL не может похвастаться.

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

>то этот трейдофф - такая же навязанная выдумка, как выбор между Зюгановым и Ельциным.

Delphi, который будучи достаточно выразительным и достаточно быстрым, компилирует раз в 50 быстрее С++. Т.е., это, на мой взгляд, оптимальный статический язык,

скорее, я тут про выбор Delphi/VCL vs. Delphi/KOL vs. Lazarus/FreePascal, а не Delphi vs. C++. Да, существенность такого выбора — вопрос спорный.

С++ - это вообще неудачная технология, её не стоит приводить в качестве опоры в каком-то выборе.

как наихудшая оценка, хуже которой уже некуда

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

Какое сравнение подменяется каким,

По-моему, я это написал достаточно однозначно.

я всё-таки не понял. То есть, компилятор языка Х лучше, чем интерпретатор языка Y или JIT-транслятора языка Z?
Я не понял смысла подмены — хороший JIT заменяет плохой интерпретатор, плохой/хороший компилятор для одного и того же языка, или, более сильно: у языка Z настолько плохо всё с интерпретацией, что ему нужен хотя бы JIT-транслятор, чтобы он был сопоставим с компилятором языка X?
Или, утверждается что JIT всегда хуже/лучше чем его отсутствие, не зависимо от языка? Потому что меняется сразу 2 ручки: язык и модель его трансляции.

Ruby по идее надо бы сравнивать со смоллтоком, или перлом — идеологически ближе. А так да, совершенно другой выбор и/или его критерии.

> Или что языки просто сделаны хорошо или плохо. Т.е., если в каком-то языке что-то плохо, то это может быть не trade-off, а просто flaw. Просто одно получилось плохо, а ничего хорошего вместо него не появилось.

если trade-off, это подразумевает более разумный выбор, если flaw — то ограничения технологии. Тут возникает вопрос, почему «ничего хорошего вместо» не появилось, несмотря на.

Может, просто исторически так сложилось. Может, сложилось неспроста.

Изучив книжку «Дилемма Инноватора» (эмпирика обширная) и всю историю протухания такого языка как Dylan, (или можно брать шире, Lisp и его способностей к интеграции с Си) — мне понятно, почему. Потому что слишком изолированная технология получилась, без преемственности, в терминах «дилеммы инноватора» это disruptive технологическая траектория, а не supportive.
С другой стороны, мне вот не очень понятно чем OpenDylan/Functional Objects был хуже дельфи. Вроде бы, не *значительно*, качественно лучше — IDE было, батарейки какие-то по безумным ценникам были; не было такой панели с компонентами, как в дельфи, и такого минимализма, как с RTL VCL/KOL (минимальное приложение на дилан  — 20 кб + 20Мб библиотек). Итого, не было особого, существенного смысла в этой технологии.

То же самое, если брать Unix/C и C/Lisp. С одной стороны, интеграцию с Си успешно решили, с другой — момент был упущен.

Большинство современных технологий - это flaw. Но чтобы это понять, нужно изучить CL.

/me записал в блокнотик, буду цитировать.

с другой стороны, это flaw ведь выполняет чей-то социальный заказ. Подобное притягивает подобное. Значит, у такой «технологической траектории» была другая система приоритетов (вроде обучения детей языку ABC, хождение по граблям Global Interpreter Lock, и т.п.), исходя из которой был сделан такой именно выбор.
(Кем был сделан такой выбор, и какая от этого польза лично мне?)

Видим: дизайн Питона - это flaw, мы потеряли скорость, но не получили взамен ничего. Он выехал только за счёт жизненной силы молодого организма, за счёт простоты базовых конструкций и пологости кривой обучения, чем CL не может похвастаться.

значит, кому-то было интересно сделать синтаксис с табуляциями. На это ушла вся творческая энергия :) а на что-то серьёзное не осталось.
С другой стороны, пишут ведь такие вещи как Nimrod, Vala/Genie, Brace, ooc и т.п.
Значит, синтаксис вайтспейса :)) востребован

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

интерпретатор языка Y или JIT-транслятора языка Z?

Язык - один, X (пусть это будет Java). Потому что, видимо, Java реализована грамотно и профессионально, чего нельзя сказать про Питон или Руби. Из всех участников гонки (статическая компиляция, AOT динамическая компиляция, JIT и интерпретация) убран очевидный фаворит, а дальше предлагают сравнивать то, что осталось. В этих условиях можно долго рассуждать, когда лучше JIT, а когда - интерпретатор. В тот момент, когда мы согласились на такое обсуждение, подмену нам уже впарили.

К тому же. Смотреть только на скорость/эффективность — это упускать ещё одно важное измерение качества. Тот факт, что такой разброс параметров по скорости/эффективности наводит на мысль, что это 3-е измерение у всех разное, и ищут его в самых странных местах.

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

армия программистов же. Вот там это третье измерение и ищут, в массовости.

> Может, просто исторически так сложилось. Может, сложилось неспроста.
В принципе, можно привести логичные причины, почему это сложилось в случае Python vs Lisp. Во-первых, думается, в то время лисп был слишком громоздким и дорого стоил. При этом, в него была вложена куча интеллектуальных сил. С другой стороны, явно абсурдный синтаксис лиспа вопиёт «убей меня». Человек сделал Python просто в меру своих сил и знаний, ясно, что он не мог тягаться с корпорациями. Постепенно произошли изменения. Лисп стал свободным и машины стали более мощными, но синтаксис закоснел и целое стадо сектантов охраняет его от любых попыток поменять синтаксис в лучшую сторону. Питон оброс мясом, но скелет остался тем же, чем и был в начале. Можно ещё вспомнить про AI winter. И добавить новые, молодые, агрессивные компании типа Sun, которым надо впарить всем свои новые технологии.

> видимо, Java реализована грамотно и профессионально, чего нельзя сказать про Питон или Руби.

/me .oO( интересно, у какой доли лисперов комплекс перед Python? )

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

интересно сравнить с Си. Почему C/Unix так резво забутстрапился и взлетел в 70х-85х гг., что аж стандарт POSIX пришлось вводить. Когда стандартизировался ANSI CL?
Почему этого не произошло с лисп-машинами. На эту тему есть статьи и книги «Why did Symbolics fail?», та же «Дилемма инноватора» и «If it works, it's not AI».
«Why did Symbolics fail?» и «Дилемма инноватора» — как можно просрать бизнес, несмотря (а может быть, из-за) более лучшей технологии. Каждый приводит свои аргументы, первое — про то что Worse vs. better, good enough vs «The Right Thing» оказалось неправильным подходом с точки зрения бизнеса. С точки зрения технологии, всё замечательно было, несмотря на заоблачные ценники находился покупатель на лисп-машины из-за пузыря AI. С точки зрения бизнеса, это тихий ужас: делать свои мониторы, свои винчестеры, и т.п. делать всё самим, дорого, но «The Right Thing». Вот IBM PC не делала всё сама, а запустила процесс с открытыми компонентами, => из-за производителей периферии возник поддерживающий его рынок, бутстрап.
«Дилемма инноватора» — профессор экономики исследует довольно много отраслей, хайтек и не хайтек, те же лисп-машины, винчестеры, автомобили и т.п. Парадокс в том, что и успешные и неуспешные фирмы делали примерно всё то же самое, лучшие инновации, пока не разорились. Он сравнивает технологии, рассуждает о «естественной технологической траектории», и о «паттернах развития» такой технологии. Классифицирует технологии на disruptive и supportive (например, мотоциклы: BMW, Harley Davidson vs. Honda, Kawasaki, и т.п. — более тяжёлые и более гибкие, резвые, что ли).
Вывод, который он делает: что supportive инновации выживают, а disruptive нет, несмотря на лучшую в тот момент технологию. Потому что disruptive сами по себе, ни с чем не совместимы, и требуют всё переделать под себя. А supportive интенсифицируют уже готовые процессы.

Можно ещё вспомнить про AI winter.

«If it works, it's not AI», «Why did Symbolics fail?» : если вкратце, пузырь AI получился из-за откатов & распилов (tm). Тоже странно: пузырь web, dotcom-- оказался более успешным. Кстати, пузырь AI позволил лисп-машинам какое-то время продержаться на плаву. А потом Sun, и т.п. рабочие станции их догнали, и предложили гораздо меньший ценник.
про «If it works, it's not AI» вообще жесть. Студентка экономфака проанализировала эфективность откатов&распилов, что-то очень мало оказалость. Ну и необоснованный оптимизм, конечно же, про те же компьютеры 5го поколения и т.п.

С другой стороны, явно абсурдный синтаксис лиспа вопиёт «убей меня».

нельзя сказать, что с этим ничего не пытались поделать — тот же arc, clojure, в некоторой степени Dylan с алгольным синтаксисом, схема, goo и т.п.

И добавить новые, молодые, агрессивные компании типа Sun, которым надо впарить всем свои новые технологии.

а кто все эти люди? Гослинг, Билл Джой, Гай Стил, тот же Gillad Bracha?
юниксоиды, лисперы, один автор емакса, другой - vi, изобретатели схемы и self, нового «функционального» смоллтока.

Поэтому, наверно, с HotSpot вышел толк. Хотя с HotSpot тоже не всё ясно. Вот в Обероне на тот момент был лучший GC, а на тему JIT — неясно что было.

Взяли, доработали, стандартизировали и преподнесли это как новую модную технологию.

Тут интересно, почему тот же Dylan vs. Java не взлетел (он одно время и преподносился как альтернатива Яве и С++). То ли у Apple настали трудные времена, то ли академики из Apple Cambridge наизобретали очередную «The Right Thing» в духе Symbolics, то ли ниасилили продавить на рынок, то ли просто поздний старт вышел. То ли он оказался просто не нужен никому на рынке Delphi и Java.

вообще за каждой такой технологией, что ни копни, кроется брат-близнец, скелет в шкафу.
У нас нет Dylan, но зато есть Java. Нет Оберона, но есть .NET. Нет лисп-машин, зато есть Си и Юникс.
Нет Амиги, но есть Линукс. Нет Plan9, но опять таки, есть Линукс.

Мало быстрых компиляторов, зато есть JIT.

>Понятно, что пока эти 15М будут грузиться, jre уже запустится и закроется, т.е., JRE тут быстрее будет, несмотря на то что байткод, а не «нативный код» :))

Щаз, одна JRE больше 15M

>лучше не Clang. Лучше какой-нибудь ooc. Под него и симпатичные llvm биндинги есть, и модель компиляции симпатичная: транслируется в Си, прозрачно линкуется с си либами

Все это конечно замечательно, но, насколько я понимаю, ни коим образом не относится к ускорению комиляции С++