E
не нген
Size: a a a
2020 November 09
AB
@Andrei_Belyaev он говорит про ngen
А я про что ссылку послал? 😊
E
если вам интересно как это в дотнете: мы компилируем байткод в нейтив с оптимизациями и каунтерами, все кроссмодульные вызовы, которые не инлайнятся - стабы. Дальше все это довольно быстро запускается т/к ничего не надо компилировать (вся базовая библиотека уже прокомпилирована в самом сдк) и джит по ходу работы приложения может выкидывать АОТ код для горячих методов и перекомпилировать уже с учетом профиля
E
нген - это раньше было, когда не было слоенной компиляции, ближе к тому что вы сейчас описываете - просто АОТ, можно с профилем заранее собранным
A
можешь дать линки?
AB
Ну, парни из Excelsior JET что-то подобное делали.
A
если вам интересно как это в дотнете: мы компилируем байткод в нейтив с оптимизациями и каунтерами, все кроссмодульные вызовы, которые не инлайнятся - стабы. Дальше все это довольно быстро запускается т/к ничего не надо компилировать (вся базовая библиотека уже прокомпилирована в самом сдк) и джит по ходу работы приложения может выкидывать АОТ код для горячих методов и перекомпилировать уже с учетом профиля
DS
Если через jaotc компилить, то вроде тоже JIT-перекомпиляция будет возможна. И там вроде Грааль компилятор используется
DS
Правда это совсем не native image
A
aot отдельных либ/модулей есть с 9ки, но как экспериментальная фича
почти что вы и описали, вроде даже был выброс аот кода в рантайме попозже
но в дикой природе я этого не видел
почти что вы и описали, вроде даже был выброс аот кода в рантайме попозже
но в дикой природе я этого не видел
A
AOT libraries can be compiled in two modes controlled by --compile-for-tiered flag:
— Non-tiered AOT compiled code behaves similarly to statically compiled C++ code, in that no profiling information is collected and no JIT recompilations will happen.
— Tiered AOT compiled code does collect profiling information. The profiling done is the same as the simple profiling done by C1 methods compiled at Tier 2. If AOT methods hit the AOT invocation thresholds then these methods are recompiled by C1 at Tier 3 first in order to gather full profiling information. This is required for C2 JIT recompilations in order to produce optimal code and reach peak application performance.
— Non-tiered AOT compiled code behaves similarly to statically compiled C++ code, in that no profiling information is collected and no JIT recompilations will happen.
— Tiered AOT compiled code does collect profiling information. The profiling done is the same as the simple profiling done by C1 methods compiled at Tier 2. If AOT methods hit the AOT invocation thresholds then these methods are recompiled by C1 at Tier 3 first in order to gather full profiling information. This is required for C2 JIT recompilations in order to produce optimal code and reach peak application performance.
E
> If AOT methods hit the AOT invocation thresholds then these methods are recompiled by C1
спорное, но интересное решение 😊
спорное, но интересное решение 😊
A
ну c1 тоже уже может оказаться лучше чем aot, так как хоть какой-то профиль уже есть
E
главное чтобы не было качель, когда метод сначало быстро на АОТ работает, потом медленно из-за С1, а потом быстро из-за С2 :D
AB
если вам интересно как это в дотнете: мы компилируем байткод в нейтив с оптимизациями и каунтерами, все кроссмодульные вызовы, которые не инлайнятся - стабы. Дальше все это довольно быстро запускается т/к ничего не надо компилировать (вся базовая библиотека уже прокомпилирована в самом сдк) и джит по ходу работы приложения может выкидывать АОТ код для горячих методов и перекомпилировать уже с учетом профиля
Надо просто определиться с термином native image. То, что ты описал - это JIT компиляция байткода. Для этого нужен CLR в любом случае. А GraalVM native image можно просто взять и без всякой JVM скопировать на другую машину.
A
на прогреве одни данные
сработал c2
потом пошли прод данные с другим профилем
работаем медленней
в какой момент решать что нужно перепрофелирование из-за изменившейся нагрузки?
сработал c2
потом пошли прод данные с другим профилем
работаем медленней
в какой момент решать что нужно перепрофелирование из-за изменившейся нагрузки?
A
так как любой откат это всегда медленней
E
Надо просто определиться с термином native image. То, что ты описал - это JIT компиляция байткода. Для этого нужен CLR в любом случае. А GraalVM native image можно просто взять и без всякой JVM скопировать на другую машину.
так у нас тоже технически, есть даже кастомер который компилит АОТ и вообще не использует джит потом, код тоже переносимый
A
но все части таскаются внутри
а это размер
мемори фупринт и вагон других вещей
а это размер
мемори фупринт и вагон других вещей
AB
так у нас тоже технически, есть даже кастомер который компилит АОТ и вообще не использует джит потом, код тоже переносимый
Стоп. Для запуска бинарника, написанного на .NET языке, нужно на другую машину ставить CLR? Если не нужно, то кто будет собирать профиль выполнения и выполнять перекомпиляцию? Или CLR в бинарь вшивается?