Короткий ответ
Это не нужно, как сейчас.
Длинный ответ
Код , который нацелен на .NET Framework Common Language Runtime (CLR) известен как управляемый код, и код , который не известен как неуправляемый.
При компиляции в управляемый код компилятор переводит ваш исходный код на промежуточный язык Microsoft (MSIL), который представляет собой независимый от процессора набор инструкций, которые можно эффективно преобразовать в собственный код.
Прежде чем вы сможете запустить промежуточный язык Microsoft (MSIL), он должен быть скомпилирован в соответствии с общеязыковой средой исполнения в собственный код для архитектуры целевой машины. .NET Framework предоставляет два способа выполнить это преобразование:
Источник: Процесс управляемого исполнения
JIT сборник
JIT-компиляция учитывает возможность того, что некоторый код никогда не будет вызываться во время выполнения. Вместо использования времени и памяти для преобразования всего MSIL в PE-файле в собственный код, он преобразовывает MSIL по мере необходимости во время выполнения и сохраняет результирующий собственный код в памяти, чтобы он был доступен для последующих вызовов в контексте этого процесса.
Источник: Процесс управляемого исполнения
Хотя теоретически JIT-компилятор мог бы использовать в своих интересах инструкции для конкретного процессора, такие как AES или AVX, такие оптимизации еще не были реализованы. Полная поддержка AVX, вероятно, появится позже с новой версией среды выполнения .NET, которая включает RyuJIT, JIT-компилятор следующего поколения, который находится в стадии разработки.
Родные изображения
[Native Image Generator (Ngen.exe) - это инструмент, который выполняет преждевременную компиляцию [из] сборок MSIL в нативный код, как это делает JIT-компилятор. Однако работа Ngen.exe отличается от работы компилятора JIT тремя способами:
Он выполняет преобразование из MSIL в собственный код перед запуском приложения, а не во время его работы.
Он компилирует всю сборку за раз вместо одного метода за раз.
Он сохраняет сгенерированный код в Nache Image Cache в виде файла на диске.
Источник: Процесс управляемого исполнения
При использовании ngen.exe для создания собственных образов выходные данные зависят от нескольких факторов, таких как идентичность сборок и версия платформы. До версии 1.1 .NET Framework выходные данные также зависели от процессора:
Если вы обновите процессор компьютера до нового семейства процессоров, все собственные изображения, хранящиеся в собственном кэше изображений, станут недействительными.
Источник: Native.exe Generator (Ngen.exe) Устаревший синтаксис
Начиная с версии 2.0, некоторые причины недействительности образа (включая тип процессора) были устранены. Кроме того, был добавлен новый переключатель /update для повторного создания недопустимых изображений. Цитирую запись в блоге, написанную Дэвидом Нотарио (выделено мной):
В предыдущих версиях CLR (1.0 и 1.1) мы относились к компиляции NGEN так же, как и к JIT-компиляции, т. Е. Учитывая, что мы компилируем на целевой машине, мы должны этим воспользоваться. Однако в Whidbey [Visual Studio 2005] это не так. Мы предполагаем набор инструкций PPro и генерируем код, как если бы он предназначался для P4. Почему это? Было несколько причин:
Повысить предсказуемость повторных сборок .NET (облегчает жизнь нашей поддержки).
OEM-производителям и другим крупным клиентам требовался один образ для каждой платформы (для обслуживания, сборки и управления).
У нас могла бы быть опция командной строки для генерирования специфичного для платформы кода в ngen , но, учитывая, что ngen главным образом должен обеспечивать лучшее поведение рабочего набора и что эта дополнительная опция усложнила бы некоторые другие сценарии, мы решили не использовать ее.
Источник: Использует ли JIT преимущества моего процессора?
В Windows 8 и более поздних версиях .NET Framework может автоматически генерировать и поддерживать собственные образы в зависимости от использования. Задача Native Image будет выполнять всю работу в фоновом режиме, когда это необходимо, и нет необходимости в ручном вмешательстве.
дальнейшее чтение
