A
Ну и тут именно уже свой ворклоад и задачи мерять
Size: a a a
2019 April 25
AW
Мне кажется это очень нишевый вопрос так что я думаю нет никаких таких таблиц ни у кого
вопрос нишевый, но он, имхо, должен возникать перед разработчиками житов
иначе почему бы не гонять ллвм каждый раз, например
иначе почему бы не гонять ллвм каждый раз, например
AW
еще есть проблема в том, что я точно не спец по жаве, поэтому даеж если я намеряю какие-то цифры, будет большой вопрос, насколько они соответствуют правде, тк я могу что-то зафакапить в настройках жавы, например
AW
Ну и тут именно уже свой ворклоад и задачи мерять
в моей ситуации, у меня нет "моего" ворклоада. Мне надо происследовать, насколько жава может быть ускорена нашими фичами и насколько от этого всем станет хуже
A
вопрос нишевый, но он, имхо, должен возникать перед разработчиками житов
иначе почему бы не гонять ллвм каждый раз, например
иначе почему бы не гонять ллвм каждый раз, например
Ну так азуловский jit falcon и построен поверх llvm со своими доработками
A
И перед разработчиками jit (сужу по докладам из оракл, интела, грааля, азул, IBM j9) почти никогда они не подымают тему скорости самого jit, всегда упор идёт на то насколько эффективным получается финальный код
A
У ораклового с1 быстрый старт
С2 больше как уже сказано было интересен финальный результат
С2 больше как уже сказано было интересен финальный результат
A
Graal выходит на пиковую производительность ещё позже чем C2, по мере работы потребляет больше памяти и cpu, но финальный код получается более оптимальный во многих случаях и может выпилить вагон алокаций объектов, там где С2 пасует и будет создавать мусор
A
У j9 они показывали свой мемори лайоут для объектов, такие недовалуе тайпы, на некоторых ворклоадах полученный код оказывется заметно быстрее, так как не нужно лишний раз по ссылке переходить
A
И практически нигде не было обсуждения вопросов "сколько мы ресурсов используем чтобы достичь этого результата", так как хоть лимит у jit на работу и есть, но все больше рассказывают о нем лишь мельком, всем интересно насколько быстрый код получится на выходе
A
Прогнать aot и получить финальный бинарник можно, но часто без про файла он оказывается медленней чем что выдаст jit со статистикой переходов и тд
A
Native image позволяет скомпилироваит с дебаг инфой, собрать профиль, перекомпилировать с профилем
A
ПФ
Да и с профайлом гарантий нет
A
Проблему сбора профиля и выход на пиковую производительность в azul решают записывая этот профиль на диск, дальше на старте перечитали с начала до конца, посмотрели где оптимизации подтвердились, где откатывались, собрали jit'ом нужные методы. Вот тут как раз наверное единственный пример когда время старта напрямую зависит от скорости jit
ПФ
Сейчас у тебя профиль, а завтра нестандартный ворклоад и прилетели
A
Это да, всегда интересовало есть ли откат когда профиль поменялся, но на trap с деоптимизациями не натыкаешься, все говорят что просто медленней будешь :(
ПФ
Это да, всегда интересовало есть ли откат когда профиль поменялся, но на trap с деоптимизациями не натыкаешься, все говорят что просто медленней будешь :(
Зависит от ВМ
A
А вот если на де оптимизации нарвался, то там есть шанс что новый профиль соберут нормально
ПФ
А, подожди, зачем откат если трэпа нет?