ПФ
Size: a a a
2018 October 15
ПФ
Потому что платят за грааль
OS
это одна и та же команда — GraalVM
OS
и если GraalVM EE хотят купить потому что там fastR быстрый — это очень важно команде fastR
ПФ
Понял :)
GF
нет, потому что это интерпретатор написанный на truflle — который делает все свои оптимизации на деревьях и все это бежит на виртуальной машине с хорошим компилятором который + еще хорошо умеет вещи которые нужны truffle - escape analysis, etc
Олег, а если это интерпретатор, что такое "прогрев", который Вы упоминали в статье?
ПФ
А это то, что я вчера рассказывал про то, как оптимизация происходит во время исполнения на основании статистики выполнения
ПФ
Вот статья на тему: https://aboullaite.me/understanding-jit-compiler-just-in-time-compiler/
ПФ
только тут всё не ограничивается С1 и C2
ПФ
Прогрев — построение абстрактной модел исполнения конкретного кода на основе статистики его исплнения. Наверное как-то так должно звучать определение. @olegchir я прав?
OS
Этот интерпретатор специализируется во время работы для конкретной программы и конкретных данных (оптимизации на уровне AST) и потом код ещё компилируется
IS
а как происходит откат в случае появления новых данных?
падает tier компляции и интерпретатор откатывается к исполнению старой версии AST?
или же в каких-то случаях решается понизить tier компиляции, но остаться на последней версии AST?
падает tier компляции и интерпретатор откатывается к исполнению старой версии AST?
или же в каких-то случаях решается понизить tier компиляции, но остаться на последней версии AST?
OS
в общем случае откат в интерпретатор
OS
вот здесь можно почитать https://chrisseaton.com/rubytruffle/pldi17-truffle/pldi17-truffle.pdf
IS
спасибо!
OC
Прогрев — построение абстрактной модел исполнения конкретного кода на основе статистики его исплнения. Наверное как-то так должно звучать определение. @olegchir я прав?
две фазы: сначала отрабатывает специализацию и прочие свои оптимизации трюфельный интерпретатор, потом то что получилось отправляется на компиляцию джитом. Насколько в этом учитывается статистика - зависит от афторов конкреного компилятора. Условно говоря, если в методе мало байткодов, его имеет смысл вообще сразу специализировать и AOT-компилировать, а если там дофига всего - то отдать джиту. Плюс у каждой оптимизации есть свой вес, и в джите имеет смысл применить только то, что влезет в отведенное время. В общем случае (для произвольной архитектуры и компилятора) - оптимизация зависит от деталей реализации компилятора, а при нарушении инвариантов - полный откат до интерпретатьора
OC
для конечного пользователя вывод - чем лучше хочется получить оптимизации, тем дольше один и тот же код должен работать на однотипных данных
ПФ
OS
для конечного пользователя вывод - чем лучше хочется получить оптимизации, тем дольше один и тот же код должен работать на однотипных данных
Так конечно не очень правильно говорить
OS
Так можно дожить до того что сказать чтобы быстрее работало надо чтоб меньше делало, что в принципе верно, но это не забота пользователя