Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, Serginio1, Вы писали:

V>>>Насколько я понимаю, в некоторой степени будет готов AOT для webasm с выходом .Net 6.0.
S>>На самом то деле он есть. И я тебе уже ссылку давал https://devblogs.microsoft.com/dotnet/conversation-about-ready-to-run/
S>>Называется Ready to run (R2R).

V>Это не то.
V>R2R идёт вместе с исходным IL и JIT.

V>Для Blazor обещали железобетонный АОТ, безо-всякого IL+JIT в нагрузку, чтобы уменьшить размер образа.
V>С этой же целью для него уже сделали триммер.

Основное премущество манагед кода это не только сборка мусора, но и рефлексия и динамическая компиляция. Очень тяжело от этого отказаться особенно в больших проектах.
Поддержка плагинов итд. Да сейчас с SG можно часть динамической компилиции перенести на компиляцию в Il код. Но все равно куча кода использует и Il генератор и Microsoft.CodeAnalysis.CSharp.Scripting

Кстати твой любимый андроид тоже использует связку JIT + AOT в ART
https://habr.com/ru/post/513928/

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

Говоря простыми словами, теперь два совершенно разных подхода работают сообща, что дает свои плюсы:

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

Кстати в комментариях

В статье не говорится, почему вернулись к схеме Interpreter+JIT+AOT. Основная проблема с AOT была, что при любом изменении системы приходилось перекомпилировать все библиотеки и приложения, что могло занимать много времени. При переходе на Interpreter+JIT+AOT одним из критериев был не ухудшение времени запуска. После перехода выяснилось, что не весь код приложений нужно компилировать.

R2R как раз и решает эту проблему.

Ключевой характеристикой формата файла является устойчивость к версиям. Это означает, что обновление зависимости совместимым способом не приведет к аннулированию скомпилированного кода AOT. Это позволяет ему вести себя аналогично формату файла IL (ECMA-335) при составлении и обслуживании приложений, который является очень гибким и простым для понимания. Предыдущие версии .Форматы файлов NET AOT, такие как формат файла, используемый NGen в .NET Framework, не обладали этим свойством.

Существует также преимущество по сравнению с наиболее оптимальным скомпилированным кодом на C++ – возможность улучшать сгенерированный код во время выполнения с помощью JIT, например, путем оптимизации для конкретной архитектуры процессора или встроенного кода из других сборок, которые не были известны во время компиляции.

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, Serginio1, Вы писали:

V>>>Насколько я понимаю, в некоторой степени будет готов AOT для webasm с выходом .Net 6.0.
S>>На самом то деле он есть. И я тебе уже ссылку давал https://devblogs.microsoft.com/dotnet/conversation-about-ready-to-run/
S>>Называется Ready to run (R2R).

V>Это не то.
V>R2R идёт вместе с исходным IL и JIT.

V>Для Blazor обещали железобетонный АОТ, безо-всякого IL+JIT в нагрузку, чтобы уменьшить размер образа.
V>С этой же целью для него уже сделали триммер.

Основное премущество манагед кода это не только сборка мусора, но и рефлексия и динамическая компиляция. Очень тяжело от этого отказаться особенно в больших проектах.
Поддержка плагинов итд. Да сейчас с SG можно часть динамической компилиции перенести на компиляцию в Il код. Но все равно куча кода использует и Деревья выражений и Il генератор и Microsoft.CodeAnalysis.CSharp.Scripting

Кстати твой любимый андроид тоже использует связку JIT + AOT в ART
https://habr.com/ru/post/513928/

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

Говоря простыми словами, теперь два совершенно разных подхода работают сообща, что дает свои плюсы:

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

Кстати в комментариях

В статье не говорится, почему вернулись к схеме Interpreter+JIT+AOT. Основная проблема с AOT была, что при любом изменении системы приходилось перекомпилировать все библиотеки и приложения, что могло занимать много времени. При переходе на Interpreter+JIT+AOT одним из критериев был не ухудшение времени запуска. После перехода выяснилось, что не весь код приложений нужно компилировать.

R2R как раз и решает эту проблему.

Ключевой характеристикой формата файла является устойчивость к версиям. Это означает, что обновление зависимости совместимым способом не приведет к аннулированию скомпилированного кода AOT. Это позволяет ему вести себя аналогично формату файла IL (ECMA-335) при составлении и обслуживании приложений, который является очень гибким и простым для понимания. Предыдущие версии .Форматы файлов NET AOT, такие как формат файла, используемый NGen в .NET Framework, не обладали этим свойством.

Существует также преимущество по сравнению с наиболее оптимальным скомпилированным кодом на C++ – возможность улучшать сгенерированный код во время выполнения с помощью JIT, например, путем оптимизации для конкретной архитектуры процессора или встроенного кода из других сборок, которые не были известны во время компиляции.