FO
если я во время работы программы докомпилирую ей .so, это будет называться JIT?
Идеальный вирус :-) своя VM: и никакой анализатор толком не поймет, что там в кишках происходит :-)
Size: a a a
2020 January 13
IU
ну, это вы просто перевели названия, ничего не сказав по сути. какая разница, в какое время пользователь запускает программу? что изменится, если я их в другом порядке запущу?
все изменится. AOT может позволить себе гораздо больше ресурсов, скушать больше памяти, компилировать достаточно долго, т.к. не конкурирует с приложением за эти самые ресурсы. Поэтому можно позволить более тяжеловесные анализы проводить и т.д. С другой стороны, чаще всего нет информации об исполнении, да и деоптимизацийнет, поэтому особо не поспекулиуешь
YS
Идеальный вирус :-) своя VM: и никакой анализатор толком не поймет, что там в кишках происходит :-)
это обычный процесс разработки
NL
Разница вообще в способе запуска. AOT компилятор нужно запустить до запуска приложение, он породит бинарь. Потом либо этот бинарь запускается сам или бинарь используется для запуска (как в HS).
YS
все изменится. AOT может позволить себе гораздо больше ресурсов, скушать больше памяти, компилировать достаточно долго, т.к. не конкурирует с приложением за эти самые ресурсы. Поэтому можно позволить более тяжеловесные анализы проводить и т.д. С другой стороны, чаще всего нет информации об исполнении, да и деоптимизацийнет, поэтому особо не поспекулиуешь
вот я об этом и говорю
YS
AOT достаточно для загрузки модулей/классов
NL
если я во время работы программы докомпилирую ей .so, это будет называться JIT?
Первый JIT у нас был именно такой: во время исполнения порождались .so (практически тем же AOT компилятором), потом грузились. Но это очень неэффективно — большие издержки по времени — правильней в память сразу порождать
NL
В такой моделе (c .so) кэширующий джит делается на халяву (переиспользуются ранее порожденные .so для последующих запусков), но правда жизни оказалось в том, что скомпилировать в память быстрее чем загрузить эти .so
NL
Именно поэтому кэширующих JIT'ов для Java нет (был у нас, но мы его выкинули)
JC
а, про греческие пробелы вроде
вопросительный знак у них как ;
BD
MaxGraey
Я это понимаю. И меня это смущает, потому как это литерал, то есть человек знает что делает это во первых, во вторых -0 существует в основном только для f32/f64. Не лучше ли выводить предупреждение? Что бы человек явно написал 0 или -0.0
Эт не литерал, это токен - и литерал 0 во многих названных тобой языках. В расте, например.
BD
сами придумали проблему, сами решили и сделали из этого пост :)
Нет, ошибки были и в других компиляторах. Просто из диагностика была невероятно странной без понимания юникода компилем
AK
а, про греческие пробелы вроде
Там было не только про пробелы, а вообще про омоглифы
МБ
нет, по-моему JIT — это не просто роль и время запуска, а набор свойств компилятора, связанный с этой ролью, например, работать с мелкими частями программы, инжектить машинный код в память
Критерий прост, imho: нужен ли компилятор во время исполнения. Если не нужен - это AOT.
МБ
Первый JIT у нас был именно такой: во время исполнения порождались .so (практически тем же AOT компилятором), потом грузились. Но это очень неэффективно — большие издержки по времени — правильней в память сразу порождать
А что при этом является более эффективным по энергии? Не измеряли такое?
AZ
Какое отношение это имеет к компиляторам?
AZ
Форварднитуда
AZ
Там и продолжим
AT
Какое отношение это имеет к компиляторам?
Компиляторы эмитят подходящие барьеры чтобы гарантировать специфицированное языком поведение.
AZ
Компиляторы эмитят подходящие барьеры чтобы гарантировать специфицированное языком поведение.
да, действительно