我相信.NET Framework 将针对安装该框架的机器的特定功能优化某些二进制文件。
将 CPU 从 Intel Nehalem 换成 Haswell 芯片后，是否需要再次手动运行优化？如果需要，流程是怎样的？
几代人之间有一些值得注意的补充：
- 韦斯特米尔：AES指令集
- 珊迪大桥：高级向量扩展
- 常春藤桥：兰德（硬件随机数生成器），F16C（16位浮点转换指令）
- 哈斯韦尔：Haswell 新指令（包括高级矢量扩展 2 (AVX2)、gather、BMI1、BMI2、ABM 和 FMA3 支持）
因此，我的想法虽然有些幼稚，但我认为优化可以在一般情况下利用这些优势。例如，调用 Random 库也许可以利用 Ivy Bridge 及更高型号上的硬件 RNG。
答案1
简短回答
到目前为止，还不需要。
长答案
针对 .NET Framework 的代码公共语言运行时（CLR）被称为管理代码，没有的代码称为未受管理。
当编译为托管代码时，编译器会将您的源代码转换为 Microsoft 中间语言 (MSIL)，这是一组独立于 CPU 的指令，可以有效地转换为本机代码。
在运行 Microsoft 中间语言 (MSIL) 之前，必须根据公共语言运行时将其编译为目标计算机体系结构的本机代码。 .NET Framework 提供了两种方法来执行此转换：
.NET Framework 即时 (JIT) 编译器。
.NET 框架本机图像生成器 (Ngen.exe)。
来源：管理执行流程
JIT 编译
JIT 编译考虑到某些代码在执行期间可能永远不会被调用的可能性。它不会花费时间和内存将 PE 文件中的所有 MSIL 转换为本机代码，而是在执行期间根据需要转换 MSIL，并将生成的本机代码存储在内存中，以便在该进程的上下文中供后续调用。
来源：管理执行流程
虽然理论上 JIT 编译器可以利用 AES 或 AVX 等特定于 CPU 的指令，此类优化尚未实现。完整AVX 支持可能会在 .NET 运行时的新版本中推出，其中包括竜日，正在开发的下一代 JIT 编译器。
本机映像Native images
[本机映像生成器 (Ngen.exe) 是一种工具，它执行] 预先编译 MSIL 程序集为本机代码，与 JIT 编译器非常相似。但是，Ngen.exe 的操作与 JIT 编译器的操作有以下三个不同之处：
它在运行应用程序之前（而不是在应用程序运行时）执行从 MSIL 到本机代码的转换。
它一次编译整个程序集，而不是一次编译一种方法。
它将生成的代码作为磁盘上的文件保存在 Native Image Cache 中。
来源：管理执行流程
当您使用ngen.exe创建本机映像时，输出取决于多个因素，例如程序集的标识和框架版本。 直到 .NET Framework 1.1 版，输出也依赖于 CPU：
如果将计算机的处理器升级到新的处理器系列，则存储在本机映像缓存中的所有本机映像都将变为无效。
从 2.0 版开始，一些导致图像无效的原因（包括 CPU 类型）已被删除。此外，/update还添加了一个新开关来重新创建无效图像。引用 David Notario 撰写的一篇博客文章（重点是我的）：
在以前的 CLR 版本（1.0 和 1.1）中，我们对待 NGEN 编译的方式与对待 JIT 编译的方式相同，也就是说，如果我们在目标机器上进行编译，我们就应该利用它。然而，在 Whidbey [Visual Studio 2005] 中，情况并非如此。我们假设一个 PPro 指令集并生成代码，就好像它以 P4 为目标一样。 为什么会这样？原因如下：
提高.NET redist 程序集的可预测性（使我们的支持工作更加轻松）。
OEM 和其他大客户希望每个平台都有一个单一的图像（出于服务、构建和管理的原因）。
我们本可以使用命令行选项来生成特定于平台的代码
ngen，但考虑到这ngen主要是为了提供更好的工作集行为，并且这个额外的选项会使其他一些场景复杂化，我们决定不这样做。
在 Windows 8 及更高版本中，.NET Framework 能够根据使用情况自动生成和维护本机映像。原生图像任务将在需要时在后台完成所有工作，无需人工干预。