Информация об изменениях

Сообщение Re[52]: MS забило на дотнет. Питону - да, сишарпу - нет? от 10.09.2021 7:23

Изменено 10.09.2021 7:34 Serginio1

Re[52]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, 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, например, путем оптимизации для конкретной архитектуры процессора или встроенного кода из других сборок, которые не были известны во время компиляции.

Re[52]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, 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, например, путем оптимизации для конкретной архитектуры процессора или встроенного кода из других сборок, которые не были известны во время компиляции.