Notice: file_put_contents(): Write of 11221 bytes failed with errno=28 No space left on device in /var/www/tgoop/post.php on line 50

Warning: file_put_contents(): Only 8192 of 19413 bytes written, possibly out of free disk space in /var/www/tgoop/post.php on line 50
Алло, это отладочная?@gdb_dbg P.301
GDB_DBG Telegram 301
Время от времени вижу обсуждение в разных чатах, мол, что лучше выбрать: JIT (компилируем код в машинный во время работы приложения, т.е. на лету) или AOT (компилируем все или почти все заранее)? Обычно в контексте Java и GraalVM.

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

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



Рассмотрим мифическую VM, где есть классный tiered JIT, классный AOT, и классный режим AOT + PGO (оптимизации в AOT с учетом заранее собранной информации о профиле). Тогда по факту есть всего три с половиной параметра, на которые нужно смотреть:

0) Время старта приложения – самое важное для вас, а пиковая производительность не важна? (да → берите AOT, нет → идем дальше),

1) Характер профиля исполнения. Есть ли в нем очевидные спайки, супер-горячие методы? Или же он плоский, все методы работают приблизительно одинаково часто, а код весь теплый? (профиль плоский → берите AOT, нет → идем дальше),

2) Меняется ли профиль во время исполнения приложения? Или же спайки всегда постоянные? (профиль постоянный → берите AOT с PGO; профиль изменчивый, или вы не знаете → берите JIT),

3) Вы выбрали JIT, но мучают постоянные, повторяющиеся деоптимизации? (вы это отпрофилировали и осознали). Возвращайтесь на AOT и радуйтесь глобальным оптимизациям.



Куча но:

1) может вам важнее ease of use и время разработки => забываем про AOT (или собираем им только финальные билды). Собирать большое приложение AOT-ом часами, это норма, нужно быть готовым страдать,

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

3) может у вас нет хорошего AOT, а профит от него очень хочется, тогда можно повставлять подпорки в JIT-ы типа CRaC-а,



Ну и главный совет: не слушайте советов из интернета. Возьмите и померьте свое конкретное приложение собранное AOT-ом или запущенное с JIT-ом. Какой будет стартап? Какой пиковый перфоманс? Идут ли потом деоптимизации? И вот основываясь на реальной информации и цифрах (на которые может повлиять миллион факторов, о которых я тут не говорю), уже делайте вывод.

#дух_машины
💯14👍5🔥2



tgoop.com/gdb_dbg/301
Create:
Last Update:

Время от времени вижу обсуждение в разных чатах, мол, что лучше выбрать: JIT (компилируем код в машинный во время работы приложения, т.е. на лету) или AOT (компилируем все или почти все заранее)? Обычно в контексте Java и GraalVM.

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

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



Рассмотрим мифическую VM, где есть классный tiered JIT, классный AOT, и классный режим AOT + PGO (оптимизации в AOT с учетом заранее собранной информации о профиле). Тогда по факту есть всего три с половиной параметра, на которые нужно смотреть:

0) Время старта приложения – самое важное для вас, а пиковая производительность не важна? (да → берите AOT, нет → идем дальше),

1) Характер профиля исполнения. Есть ли в нем очевидные спайки, супер-горячие методы? Или же он плоский, все методы работают приблизительно одинаково часто, а код весь теплый? (профиль плоский → берите AOT, нет → идем дальше),

2) Меняется ли профиль во время исполнения приложения? Или же спайки всегда постоянные? (профиль постоянный → берите AOT с PGO; профиль изменчивый, или вы не знаете → берите JIT),

3) Вы выбрали JIT, но мучают постоянные, повторяющиеся деоптимизации? (вы это отпрофилировали и осознали). Возвращайтесь на AOT и радуйтесь глобальным оптимизациям.



Куча но:

1) может вам важнее ease of use и время разработки => забываем про AOT (или собираем им только финальные билды). Собирать большое приложение AOT-ом часами, это норма, нужно быть готовым страдать,

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

3) может у вас нет хорошего AOT, а профит от него очень хочется, тогда можно повставлять подпорки в JIT-ы типа CRaC-а,



Ну и главный совет: не слушайте советов из интернета. Возьмите и померьте свое конкретное приложение собранное AOT-ом или запущенное с JIT-ом. Какой будет стартап? Какой пиковый перфоманс? Идут ли потом деоптимизации? И вот основываясь на реальной информации и цифрах (на которые может повлиять миллион факторов, о которых я тут не говорю), уже делайте вывод.

#дух_машины

BY Алло, это отладочная?


Share with your friend now:
tgoop.com/gdb_dbg/301

View MORE
Open in Telegram


Telegram News

Date: |

‘Ban’ on Telegram Deputy District Judge Peter Hui sentenced computer technician Ng Man-ho on Thursday, a month after the 27-year-old, who ran a Telegram group called SUCK Channel, was found guilty of seven charges of conspiring to incite others to commit illegal acts during the 2019 extradition bill protests and subsequent months. Ng Man-ho, a 27-year-old computer technician, was convicted last month of seven counts of incitement charges after he made use of the 100,000-member Chinese-language channel that he runs and manages to post "seditious messages," which had been shut down since August 2020. The SUCK Channel on Telegram, with a message saying some content has been removed by the police. Photo: Telegram screenshot. Private channels are only accessible to subscribers and don’t appear in public searches. To join a private channel, you need to receive a link from the owner (administrator). A private channel is an excellent solution for companies and teams. You can also use this type of channel to write down personal notes, reflections, etc. By the way, you can make your private channel public at any moment.
from us


Telegram Алло, это отладочная?
FROM American