优化增强您的Visual C＋＋应用程序

虽然 Microsoft® .NET Framework 确实能提高开发人员的工作效率，但许多人对托管代码的性能还是有些担忧。新版本的 Visual C++®  将会让您消除这些担忧。对于 Visual Studio® 2005，C++ 语法本身得到了很大的改进，从而使它编写更加迅速。另外，还提供了一个灵活的语言框架来与公共语言运行库 (CLR) 相交互以便于编写高性能的程序。

　　许多编程人员认为 C++ 之所以能带来高性能，是因为它生成本机代码，但即使您的代码完全托管，仍然可以获得出众的性能。通过灵活的编程模型，C++ 不会让您束缚在面向过程编程、面向对象编程、可再生编程或者元编程。

　　另一个常见的误解是：不管使用什么语言，在 .NET Framework 中都能获得同样好的性能 — 通过各种编译器生成的 Microsoft 中间语言 (MSIL) 本质上是等同的。即使在 Visual Studio .NET 2003 中也无法这样，但在 Visual Studio 2005 中，C++ 编译器团队致力于确保优化本机代码多年所获得的所有经验都能够应用到托管代码优化上。C++ 为您提供充分的灵活性来进行更好的优化，比如进行高性能封送处理，这在其他语言中是无法做到的。此外，Visual C++ 编译器还生成任何 .NET 语言中最优化的 MSIL。结果是 .NET 中最优化的代码来自 Visual C++ 编译器。

　　优化的MSIL

　　在 .NET 环境中，编译分为两个不同的部分。第一部分为编程人员通过语言编译器(C#、Visual Basic? 或 Visual C++)进行编译和优化，以生成 MSIL。第二部分包括将 MSIL 送到实时 (JIT) 编译器或 NGEN，由它读取 MSIL 并随后生成优化的本机代码。显然，语言编译器和 JIT 是不可分离的组件，这意味着要生成好的代码，二者必须协同工作。

　　Visual C++ 始终提供任何编译器的最高级优化设置。这在托管代码中也没有改变。甚至在 Visual C++ .NET 2003 中这一点也很明显，它只是通过用于生成 MSIL 代码的本机编译器开始启用优化。

　　在 Visual C++ 2005 中，编译器可以对 MSIL 代码执行标准本机代码优化很大的子集。从基于数据流的优化到表达式优化，再到循环展开，这一切都包含在内。平台中的其他任何语言都无法做到这一级别的优化。在 Visual C++ .NET 2003 中，全程序优化 (Whole Program Optimization, WPO) 不支持使用 /clr 开关构建，但 Visual C++ 2005 为托管代码添加了这个功能。这个功能启用了跨模块优化，本文后面将会对其进行讨论。

　　在 Visual C++ 2005 中，托管代码唯一不可用的一种优化是 Profile Guided Optimizations，虽然在以后的版本中可能可用。有关更多信息，请参阅 Write Faster Code with the Modern Language Features of Visual C++ 2005。

　　JIT 和编译器优化交互

　　Visual C++ 生成的优化代码提供给 JIT 或 NGEN 以生成本机代码。不管 Visual C++ 编译器生成的代码是 MSIL 还是非托管代码，生成代码的优化器还是十几年前就已开发并已进行调整的优化器。

　　对 MSIL 代码的优化是对非托管代码进行优化的一个大子集。需要指出的是，允许的优化类随编译器生成的是可验证代码 (/clr:safe) 或非可验证代码 (/clr or /clr:pure) 的不同而不同。在少量的几种情况下，编译器会因为元数据或可验证性限制而无法完成操作，包括缩减运算量(将相乘转换成指针相加)，以及将对一个类的私有成员的访问内联到另一个类的方法体中。

　　Visual C++ 编译器生成 MSIL 代码之后，就可以交给 JIT 进行处理。JIT 读取 MSIL 并开始执行优化，这些优化对 MSIL 中的变化很敏感。一个 MSIL 指令序列也许能够很好地进行优化，但另一个(语义上等同的)序列却可能抑制优化。例如，寄存器分配是一个优化，在这个优化中，JIT 优化器试图将变量映射到寄存器中;寄存器是作为执行算术和逻辑运算的操作数使用的实际硬件。有时，语义上等同但采用两种不同方式编写的代码可能会使优化器在执行良好的寄存器分配上所花费的时间相差巨大。循环展开是一个可能导致 JIT 分配寄存器出现问题的转换的例子。

　　C++ 编译器完成的循环展开可以公开更多的指令级并行，但也创建了更多活变量 (live variable)，编译器需要使用它们来跟踪寄存器分配。CLR JIT 只能跟踪固定数目的寄存器分配变量;一旦需要跟踪的数目超出这个数目，它就开始将寄存器的内容移到内存中。

　　因此，必须先后对 Visual C++ 编译器和 JIT 进行微调以生成最佳代码。Visual C++ 编译器负责进行的优化是那些对 JIT 来说太耗时的优化，以及那些在从 C++ 源代码编译为 MSIL 的编译过程中会造成太多信息丢失的优化。

　　让我们看一下 Visual C++ 对托管代码的一些优化。

　　公共子表达式消除和代数简化

　　公共子表达式消除(Common subexpression elimination，CSE)和代数简化 (algebraic simplification) 是两个强大的优化，它们允许编译器在表达式级别执行一些基本优化，以便开发人员可以专注研究算法和体系结构。

　　下面显示的代码片段分别作为 C# 和 C++ 编译;二者都是在 Release 配置下编译的。变量 a、b 和 c 从一个作为参数传递的数组复制到包含这段代码的函数中：

以下是引用片段： 　　int d = a + b * c; 　　int e = (c * b) * 12 + a + (a + b * c);

　　图 1 显示了 C# 编译器和 C++ 编译器通过这段代码生成的 MSIL，它们都启用了优化。C# 需要 19 条指令，而 C++ 只需 13 条。另外，您可以看到 C++ 代码可以对 b*c 表达式进行 CSE。该编译器可以对 a+a 进行代数简化，即改为生成 2*a，也可以对 (c*b)*12 + c*b 进行代数简化，即改为生成 (c*b)*13。我发现增加的这个 CSE 特别有用，因为我见过编程人员在实际的代码中没有进行这种代数简化。请参阅补充内容“C# 编译器优化”。

　　全程序优化

　　Visual C++ .NET 对非托管代码添加了 WPO。而在 Visual C++ 2005 中，这个功能扩展到了托管代码。它不是一次编译和优化一个源文件，而是一次跨所有源文件和头文件进行编译和优化。

　　现在编译器可以跨多个源文件执行分析和优化。例如，如果没有 WPO，编译器只能在单个编译域中内联函数。有了 WPO，编译器就可以从程序中的所有源文件内联函数。

　　在以下的示例中，编译器可以做的事情包括跨编译器内联和常量传递，以及其他类型的过程间优化：

以下是引用片段： 　　// Main.cpp 　　... 　　MSDNClass ^MSDNObj = gcnew MSDNClass; 　　int x = MSDNObj->Square(42); 　　return x; 　　... 　　// MSDNClass.cpp 　　int MSDNClass::Square(int x) 　　{ 　　return x*x; 　　}

　　在这个示例中，Main.cpp 调用 Square 方法，而这个方法是另一个源文件中的 MSDNClass 的一部分。当编译时进行 /O2 优化，而不进行全程序优化时，Main.cpp 中产生的 MSIL 如下所示：

　　ldc.i4.s 42

　　call instance int32 MSDNClass::Square(int32)

　　您可以看到，它首先将值 42 加载到堆栈中，然后调用 Square 函数。作为对照，对于相同的程序，当编译时打开全程序优化时，则生成的 MSIL 如下所示：

　　ldc.i4 0x6e4

　　它没有加载 42，也没有调用 Square 函数。相反，在全程序优化下，编译器可以内联来自 MSDNClass.cpp 的函数并进行常量传递。最终的结果只是一条简单的指令 — 加载 42*42 的结果，十六进制表示为 0x6e4。

　　虽然 Visual C++ 编译器执行的一些分析和优化在理论上 JIT 编译器也可以执行，但对 JIT 编译器的时间限制使得这里提到的许多优化当前还无法实现。一般情况下，NGEN 会比 JIT 编译器更早实现这些类型的优化，因为 NGEN 没有 JIT 编译器必须面对的这类响应时间限制。