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


VD>Дык мы в этой теме обсуждаем портирование Немерла (точнее того расширяемого языка который мы планируем делать в этом году) под нйтив. Речь идет о создании LLVM-бэкэнда к нитре и реализации собственного рантайма.

VD>Нас как-то не сильно волнует, что это будет совсем не .net.

S>> Сейчас 2 Силара второй Core c .Net Native

VD>И что? Там скорее доптимизации из-за переносимости.

.NET Native и NGEN

Генератор образов в машинном коде (NGEN) компилирует сборки в машинный код и устанавливает их в кэш образов в машинном коде на локальном компьютере. Однако хотя NGEN, как и .NET Native, создает машинный код, NGEN имеет существенные отличия от .NET Native:
Если для конкретного метода нет образа в машинном коде, NGEN переключается на JIT-компиляцию кода. Это означает, что образы в машинном коде должны продолжать включать метаданные и IL-код для того случая, если генератору NGEN необходимо переключиться на JIT-компиляцию. В противоположность этому .NET Native только создает образы в машинном коде и не переключается на JIT-компиляцию. В результате должны сохраняться метаданные, необходимые только для некоторых сценариев отражения, сериализации и взаимодействия.
NGEN по-прежнему полагается на полную среду CLR для таких сервисов, как загрузка сборок, удаленное и локальное взаимодействие, управление памятью, сбор мусора и, при необходимости, JIT-компиляция. В .NET Native многие из этих сервисов являются либо ненужными (JIT-компиляции), либо разрешаются во время построения и включаются в сборку приложения. Остальные сервисы, наиболее важным из которых является сбор мусора, включены в гораздо более компактную, оптимизированную среду выполнения mrt100_app.dll.
Образы NGEN, как правило, хрупкие. Например, обновление или изменение зависимости обычно требует, чтобы сборки, которые его используют, также были пересозданы NGEN. Это особенно верно для системных сборок в библиотеке классов .NET Framework. В противоположность этому .NET Native позволяет обслуживать приложения независимо друг от друга.

Ссылка на файл конфигурации директив среды выполнения (rd.xml)


вы будете делать тоже самое

Посмотри

Введение в IL2CPP

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


VD>Дык мы в этой теме обсуждаем портирование Немерла (точнее того расширяемого языка который мы планируем делать в этом году) под нйтив. Речь идет о создании LLVM-бэкэнда к нитре и реализации собственного рантайма.

VD>Нас как-то не сильно волнует, что это будет совсем не .net.

S>> Сейчас 2 Силара второй Core c .Net Native

VD>И что? Там скорее доптимизации из-за переносимости.

.NET Native и NGEN

Генератор образов в машинном коде (NGEN) компилирует сборки в машинный код и устанавливает их в кэш образов в машинном коде на локальном компьютере. Однако хотя NGEN, как и .NET Native, создает машинный код, NGEN имеет существенные отличия от .NET Native:
Если для конкретного метода нет образа в машинном коде, NGEN переключается на JIT-компиляцию кода. Это означает, что образы в машинном коде должны продолжать включать метаданные и IL-код для того случая, если генератору NGEN необходимо переключиться на JIT-компиляцию. В противоположность этому .NET Native только создает образы в машинном коде и не переключается на JIT-компиляцию. В результате должны сохраняться метаданные, необходимые только для некоторых сценариев отражения, сериализации и взаимодействия.
NGEN по-прежнему полагается на полную среду CLR для таких сервисов, как загрузка сборок, удаленное и локальное взаимодействие, управление памятью, сбор мусора и, при необходимости, JIT-компиляция. В .NET Native многие из этих сервисов являются либо ненужными (JIT-компиляции), либо разрешаются во время построения и включаются в сборку приложения. Остальные сервисы, наиболее важным из которых является сбор мусора, включены в гораздо более компактную, оптимизированную среду выполнения mrt100_app.dll.
Образы NGEN, как правило, хрупкие. Например, обновление или изменение зависимости обычно требует, чтобы сборки, которые его используют, также были пересозданы NGEN. Это особенно верно для системных сборок в библиотеке классов .NET Framework. В противоположность этому .NET Native позволяет обслуживать приложения независимо друг от друга.

Ссылка на файл конфигурации директив среды выполнения (rd.xml)

Сериализация и метаданные

вы будете делать тоже самое

Посмотри

Введение в IL2CPP