Resposta curta
Não precisa, a partir de agora.
Resposta longa
O código que visa o .NET Framework Common Language Runtime (CLR) é conhecido como gerenciado código e código que não é conhecido como não gerenciado .
When compiling to managed code, the compiler translates your source code into Microsoft intermediate language (MSIL), which is a CPU-independent set of instructions that can be efficiently converted to native code.
Before you can run Microsoft intermediate language (MSIL), it must be compiled against the common language runtime to native code for the target machine architecture. The .NET Framework provides two ways to perform this conversion:
A .NET Framework just-in-time (JIT) compiler.
The .NET Framework Native Image Generator (Ngen.exe).
Source: Managed Execution Process
Compilação JIT
JIT compilation takes into account the possibility that some code might never be called during execution. Instead of using time and memory to convert all the MSIL in a PE file to native code, it converts the MSIL as needed during execution and stores the resulting native code in memory so that it is accessible for subsequent calls in the context of that process.
Source: Managed Execution Process
Embora, em teoria, o compilador JIT possa aproveitar as instruções específicas da CPU, como AES ou AVX, essas otimizações ainda não foram implementadas. Full provavelmente virá mais tarde com uma nova versão do runtime .NET que inclui RyuJIT , o compilador JIT next-gen que está sendo desenvolvido.
Imagens nativas
[The Native Image Generator (Ngen.exe) is a tool that performs an] ahead-of-time compilation [of] MSIL assemblies to native code much like the JIT compiler does. However, the operation of Ngen.exe differs from that of the JIT compiler in three ways:
It performs the conversion from MSIL to native code before running the application instead of while the application is running.
It compiles an entire assembly at a time, instead of one method at a time.
It persists the generated code in the Native Image Cache as a file on disk.
Source: Managed Execution Process
Quando você usa ngen.exe para criar imagens nativas, a saída depende de vários fatores, como a identidade dos assemblies e a versão da estrutura. Até a versão 1.1 do .NET Framework, a saída também dependia da CPU:
If you upgrade a computer's processor to a new processor family, all native images stored in the native image cache become invalid.
A partir da versão 2.0, algumas causas de invalidação de imagem (incluindo o tipo de CPU) foram removidas. Além disso, uma nova opção /update foi adicionada para recriar imagens inválidas. Citando uma entrada de blog escrita por David Notario (ênfase minha):
In previous versions of the CLR (1.0 and 1.1), we treated NGEN compilation the same way as we treated JIT compilation, ie , given that we are compiling in the target machine, we should take advantage of it. However, in Whidbey [Visual Studio 2005], this is not the case. We assume a PPro instruction set and generate code as if it was targeting a P4. Why is this? There was a number of reasons:
Increase predictability of .NET redist assemblies (makes our support life easier).
OEMs and other big customers wanted a single image per platform (for servicing, building and managing reasons).
We could have had a command line option to generate platform specific code in
ngen, but given thatngenis mainly to provide better working set behavior and that this extra option would complicate some other scenarios, we decided not to go for it.
No Windows 8 e versões posteriores, o .NET Framework é capaz de gerar e manter automaticamente imagens nativas com base no uso. A tarefa de imagem nativa fará todo o trabalho em segundo plano sempre que necessário, e não há necessidade de intervenção manual.