Сравнение производительности MJIT и TruffleRuby

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

Иногда время старта важнее производительности после прогрева, иногда — наоборот. Обеим имплементациям найдется применение.

Вот очевидно, что жаба тормозит. Микробенчмарки она успеет прогреть. А какую-нибудь IDEA сколько времени она прогревает?

Учитывая, что по микробенчмаркам жаба всё же медленнее Си (если верить «benchmarksgame.alioth.debian.org», то жаба по сравнению с нормальными компилируемыми языками - в чистом минусе. Так было, есть и будет всегда. Наверное, поэтому они в конце концов были вынуждены прикрутить AOT компиляцию. А ты просто повторяешь рекламу (я читал почти дословно твой коммент в какой-то квазирекламной статье про AOT компиляций для жабы).

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

К примеру: IDEA у меня запущена примерно 2-3 недели. Это обычный юз кейс. Я бы считал что IDEA прогрета по умолчанию.

AOT копилятор для жабы придумали очень давно и он успешно прадаётся (привет ребятам из сибири - https://www.excelsiorjet.com)
Почему оракл захотел что-то подобное - потму что есть спрос. Некоторые хотят. Рынок требует. Нужно расширят своё предложение, деньги зарабатывать.

Ну, хорошо, что IDEA достигла такого уровня стабильности, что не падает столько времени (я смотрел её на протяжении пары часов за всю свою жизнь). Тогда на IDEA эта проблема не распространяется :) Видимо, остаются некоторые другие программы.

Наверное, поэтому они в конце концов были вынуждены прикрутить AOT компиляцию.

Нет. Не думаю, что дело в микробенчмарках.

я читал почти дословно твой коммент в какой-то квазирекламной статье про AOT компиляций для жабы

Возможно, это потому что мысль простая и правильная(применима и к Java, и к Ruby).

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

Нет. Не думаю, что дело в микробенчмарках.

Дело не в них. Напротив, мне кажется, что на микробечмарках разогрев идёт гораздо быстрее. Т.е на обычном коде из жизни жаба будет гораздо хуже выступать, чем на микробенчмарках. А у плюсов такого эффекта нет.

Есть бенчмарки web фреймворков и там java все равно в топе, обгоняя даже хваленые golang, D и node. Хотя приложение на здроровенном фреймворке микробенчмарком никак не назовешь

https://www.techempower.com/benchmarks/#section=data-r14&hw=ph&test=json

Ну, если дело касается простых утилит типа cp, grep, cat и т.п., то ничего лучше не придумали, чем Ада, Си, Си++, Rust, паскаль (из современных), где нет сборщика мусора.

Чуть сложнее логика - там уже может быть польза от сборки мусора, потому что, теряя в одних местах, начинаем здорово выигрывать в других. Тут и go, haskell, ocaml, лиспы (настоящие) могут показать очень хорошие результаты. И даже выглядеть лучше, чем языки из предыдущей группы в некоторых задачах, в том числе, по скорости исполнения.

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

Пример. Веб-серверы очень редко когда перезапускаются, разве что при апгрейде. Там ява очень хорошо смотрится. Ну, а если кто вздумает заменить на Си++, то пусть вспомнит судьбу корбы, и что с нею в итоге стало :)

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

Спасибо, интересно! Видимо, они тестили достаточно долго, чтобы она прогрелась. А что такое там «framework overhead»?

при этом приложение не так часто и стартует, то тут и виртуальная машина не так заметна.

Вот именно. Добавили бы они сразу AOT компиляцию - была бы универсально применимая платформа. А так - все эти JIT-виртмашины - только для определённых ниш. Заполнив эти ниши, они лезут во все стороны, в итоге мы все пользуемся тормозным софтом.

В .NET есть стандартный AOT-компилятор, который называется ngen, если мне склероз не изменяет. Когда-то проверял с ним и без него такое небольшое десктопное приложение. Разницы не заметил.

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

А для явы есть AOT-компиляция. Из Сибири. Давно продают за деньгу. А недавно в андроид завезли, начиная толи с версии 5, толи 6.

Только по моему скромному разумению вся это возня с AOT для дот-нета и явы как мертвому припарка, потому как повсеместно используется рефлексия. Непонятно, в общем, есть ли польза от AOT.

И есть даже что-то типа очень распространенного суеверия, что ни-ни, никакой оптимизации кода до JIT быть не должно, а то Кнут заругает за «преждевременную оптимизацию»

Да и динамическая загрузка классов тоже используется очень и очень широко. Короче, есть AOT или нет, не отменяет того факта, что JIT нужен все равно. А если нужен JIT, но на пуркуа еще тогда AOT?

Ну это так спроектировано в Java, что рефлексия завязана на байткод. В С++ рефлексия есть, байткода нет. Динамическая загрузка классов тоже никак не связана с байткодом - есть же бинарные разделяемые библиотеки. Да, есть custom class loaders ,но подобные механизмы можно предусмотреть и для машинного кода. Хотя можно по-разному трактовать термин JIT. Например, можно считать, что в лиспе тоже JIT, а разогрев Ява - машины - это частный случай под названием «Profile-Guided Optimization Using Background JIT».

Поэтому, несмотря на то, что Java показывает очень хорошие результаты по бенчмаркам, я продолжаю считать, что «Profile-Guided Optimization Using Background JIT» - это опция второстепенного значения, а правильный дизайн - в CL, когда есть явная JIT компиляция и возможность хранения машинного кода в fasl-ах и в сохранённых образах. Если бы к этому можно было добавить ещё image-based development, как он есть в SQL, и столь же регулярную рефлексию, то было бы вообще супер. Но и SLIME-режим, когда исходники хранятся во внешних файлах, тоже вполне себе годнота.

Мои оргвыводы из вышесказанного состояли в том, что на протяжении всей карьеры я держался в стороне и от Java, и от C#. Красивые и осмысленные технологии - это лисп, sql, может быть в какой-то степени С и ассмеблер. А java и C# - нет, несмотря на всю мощь, которую они набрали.

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

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

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

Например, расширения для MRI на C после прогрева быстрее на TruffleRuby, чем MRI, за счет того, что C и Ruby можно оптимизировать вместе.

(Стоить заметить, что статья старая, 2014-го года, сейчас от TruffleC уже отказались в пользу Sulong. Преимущества для оптимизации сохраняются при таком подходе, но теперь есть зависимость от внешнего компилятора, который должен перевести C в LLVM-биткод.)

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

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

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

Да... Жесть короче. Спасибо за тему, не знал про этот Грааль ничего.

Да и динамическая загрузка классов тоже используется очень и очень широко. Короче, есть AOT или нет, не отменяет того факта, что JIT нужен все равно. А если нужен JIT, но на пуркуа еще тогда AOT?

1. Чтобы можно было распространять софт одним статическим бинарником, без JVM.

2. Чтобы существенно улучшить время старта. В этой статье(«TruffleRuby on the Substrate VM») сравнивается время выполнения ruby -e 'p "Hello, world"':

TruffleRuby JVM 0.20  3.43
TruffleRuby SVM 0.20  0.24
MRI 2.4.0             0.05

При этом ожидается, что производительность после прогрева должна быть примерно одинаковой на JVM и SVM, потому что и там, и там JIT будет осуществляться Graal'ем:

It should be very similar, because Just-in-Time compilation as done by Graal is performed in both cases. However, SVM is a different VM and might have different trade-offs, GCs, and optimizations than HotSpot.

3. Чтобы получить, что-то похожее на Smalltalk-образы, которые будут универсальны для большого количества языков:

The way that the SubstrateVM works is that you can run the interpreter up until a certain point and then stop execution and freeze the heap at that point for compilation, producing an executable which resumes executing from that point.

Будет очень круто, если Oracle допилит и откроет исходники SubstrateVM.

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

Что упаковали? Пардон, совсем не понял вашей мысли.

Т.е., чтобы программы работали не слишком быстро.

В статье, на которую я дал ссылку, объяснено почему некоторые программы будут работать быстрее, чем собранные GCC.

Упаковали компилятор не как в лиспе (компилируй инкрементно и сохраняй результаты компиляции в исполняемый файл), а так, что компиляция вызывается при каждой загрузке (если без AOT). Это и есть «неудобно».

В статье, на которую я дал ссылку, объяснено почему некоторые программы будут работать быстрее, чем собранные GCC.

Это понятно, 20 лет прошло, и конкуренты стали поджимать, те же Rust и Golang. Вот они и делают послабления. Хотя я не знаю ещё, до чего дойдёт этот проект. Они ведь вполне могут его и закрыть в определённый момент.

Упаковали компилятор не как в лиспе (компилируй инкрементно и сохраняй результаты компиляции в исполняемый файл), а так, что компиляция вызывается при каждой загрузке (если без AOT). Это и есть «неудобно».

Так наоборот ведь. Делают SubstrateVM, чтобы было «удобно».

Вот они и делают послабления.

Почему «послабления»? Это ведь инновации.

инновации.

Если взять АОТ компиляцию как таковую, она не была инновацией и в 1968 году. Т.е. вопрос «а нахрена не была сделана AOT в Java сразу» так и остался неотвеченным. Вариант «Это трудоёмко» не подходит, т.к. они сделали больше, чем компилятор. Значит, сделать AOT было бы совсем нетрудно. Но не сделали. Моё мнение - целенаправленно и по причинам, лежащим вне техники.

Результат: по сей день программы на Си значительно быстрее и требуют меньше памяти, чем на Java, во всяком случае, по микробенчмаркам и «на глаз».

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

Делают SubstrateVM, чтобы было «удобно».

Ну дай бог, если у них всё получится хорошо. Я не спорю с тем, что идея преобразовывать интерпретаторы в компиляторы автоматически _может_ быть жизненной (а может и не быть). Но кроме быстроты и лёгкости, интересен ещё и качественный результат. Критерий качества - gcc и luaJit. Теперь можно ещё на Rust смотреть - он тоже быстр.

Вот когда с помощью грааля или каких-то других вещей руби обойдёт gcc по широкому фронту - можно будет кричать «ура!». Насколько я понял, этого пока не произошло.

КОроче говоря, там не хватает колонки «Си»

Вариант «Это трудоёмко» не подходит, т.к. они сделали больше, чем компилятор. Значит, сделать AOT было бы совсем нетрудно.

Не понимаю вашей логики. Как из того, что они сделали больше, чем компилятор, следует, что сделать АОТ было совсем нетрудно?

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

Еще у C относительно простая семантика(которая упрощает компиляцию и усложняет разработку).

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

Как вы пришли к такому выводу? Мне он не кажется правдоподобным.

Как из того, что они сделали больше, чем компилятор, следует, что сделать АОТ было совсем нетрудно?

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

Еще у C относительно простая семантика

Ну, конечно, есть у Java свои особенности, связанные хотя бы со сборкой мусора, к-рые объективно замедляют. Можно ли на них списать все тормоза? Я не знаю. Опять же, Common Lisp умеет инкрементную AOT компиляцию, умеет сохранять образы, умеет транслироваться в Си, всё это он умеет делать разными путями (в нескольких реализациях) и на разных платформах. Я почти полностью уверен, что всё это он умел и в 1995 году, и что создатели Java про это знали. В некоторых ОС для любой программы (написанной на любом языке) можно было сохранить core и потом перезапустить его, так что в технологии сохранения образа тоже нет никаких чудес. Да, сейчас CL медленнее Явы по бенчмаркам, не учитывающим время разогрева. Но Ява уже давно доминирует, а лисп поддерживает горстка людей.

Как вы пришли к такому выводу? Мне он не кажется правдоподобным.

Да вы посмотрите, что делает любой бизнес. Его целью никогда не является техническое совершенство. Цель - сделать деньги (а когда бизнес совсем большой, он начинает интересоваться властью над людьми и думать о мировом господстве). Java - это коммерческий проект, почему, собственно, они должны были преследовать благородные цели? Одну вещь они дали - надёжность (нет таких грабель, как в Си). Но эту вещь они дали не с целью осчастливить человечество, а с целью поднять бабла. Т.е. они её не подарили, а продали. Чем мы расплатились? Где-то мы должны обнаружить убыль у себя.

Яркий пример - микрософт. Очевиден резкий рост прожорливости к ресурсам в каждой следующей версии ОС от МС (может быть, исключения и есть, но по линии win 3.1 - 98 - xp - 7 это было вполне очевидно). Также утверждалось, что Microsoft получает несколько десятков $ с каждого проданного процессора Intel. Также были статьи, где обсуждалось, как именно Microsoft будет замедлять работу своих ОС на чипах AMD.

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

Но давайте на этом уже закруглимся. Моя точка зрения может казаться весьма экстремальной, я привёл столько аргументов, сколько мог, далее не имею ресурсов.

В некоторых ОС для любой программы (написанной на любом языке) можно было сохранить core и потом перезапустить его

Не смог вспомнитЬ, в какой ОС так можно, но был подобный проект для Linux:

https://github.com/maaziz/cryopid

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