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

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

S>> То есть ты утверждаешь, что на С++ невозможно компилить код для 6 платформ?
S>>IL код прекрасно транслируется в С++. А кто там, что пишет мне неизвестно. Я даже нативными библиотеками не пользуюсь. Вернее если и пользуюсь, то они где то далеко скрыты в PInvoke
S>>и их минимум.

S>Как IL транслировать в C++ ? Дай пример — посмотрим что там получается. Что со сборкой мусора?
Я уже давал тебе ссылки на Il2CPP. Смотри Unity на том же яблоке.
Но IL2CPP старый проект надо смотреть Native AOT
Кстати про заголовочные файлы https://github.com/dotnet/runtime/issues/100747

По .Net Native больше информации
https://learn.microsoft.com/ru-ru/windows/uwp/dotnet-native/net-native-and-compilation#just-in-time-compilation

.NET Native заменяет полную среду CLR на оптимизированную среды выполнения, которая в первую очередь содержит сборщика мусора. Оптимизированная среда выполнения находится в библиотеке mrt100_app.dll, которая является локальной для приложения и имеет размер только несколько сотен килобайт. Это возможно потому, что статическое связывание устраняет необходимость во многих операциях, реализуемых средой CLR.

Примечание

.NET Native использует тот же сборщик мусора, что и стандартная среда CLR. В сборщике мусора .NET Native фоновая сборка мусора включена по умолчанию. Дополнительные сведения о сборке мусора см. в разделе Основы сборки мусора.

Здесь про производительность про эволюцию Native AOT .Net 8 vs .Net 9.
Вообще MS вкладываются в развитие Native AOT
https://devblogs.microsoft.com/dotnet/performance-improvements-in-net-9/

Усовершенствования встраивание для собственного AOT

Тут нашел
https://www.linux.org.ru/forum/development/17559964/page1?ysclid=m2608onp93145387422

По словам Claude.ai:

Here are some key points about garbage collection in .NET Native AOT-compiled binaries:

GC Design: The .NET Native GC is designed to be simpler and more predictable than the traditional .NET GC. It uses a non-compacting, mark-and-sweep algorithm, which avoids the need for compaction and simplifies the GC implementation.
AOT Compilation: During the AOT compilation process, the compiler analyzes the code and generates GC information and metadata that is embedded in the final binary. This metadata is used by the AOT GC at runtime.
GC Triggering: The AOT GC is triggered based on a simple threshold mechanism. When the amount of allocated memory crosses a predefined threshold, the GC is triggered to reclaim unused memory.
Thread Suspension: Unlike the traditional .NET GC, which suspends all threads during a collection, the .NET Native GC uses a concurrent marking phase that allows threads to continue running during most of the collection cycle.
Memory Layout: The .NET Native GC uses a different memory layout compared to the traditional .NET runtime. It separates the managed heap into different regions, including the new object space, the large object space, and the pinned object space.
Performance Characteristics: The .NET Native GC is designed to be more deterministic and predictable in terms of performance, at the cost of some throughput compared to the traditional .NET GC. This predictability is important for scenarios like ahead-of-time compiled apps, where consistent performance is crucial.
Btw., следующий релиз .NET v9 нацелен на cloud-native приложения, наверно, Goкрыс на мороз будут выпинывать?