[转]优化增强您的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 编译器必须面对的这类响应时间限制。
64 位 NGEN 优化
出于本文需要，我将 JIT 和 NGEN 统称为 JIT。对于 32 位版本的 CLR，JIT 编译器和 NGEN 执行的优化相同。但 64 位版本的却不是这样，在 64 位版本中，NGEN 比 JIT 所进行的优化明显更多。
64 位的 NGEN 利用了这样的事实：它可以比 JIT 花费更多的时间进行编译，因为 JIT 的吞吐量直接影响应用程序的响应时间。我在本文特别提到了 64 位的 NGEN，因为它针对 C++ 风格的代码进行相对地微调，它进行的一些优化(例如双 Thunk 消除优化)对 C++ 起到很大的帮助，这些优化是其他 JIT 和 NEGN 所不具备的。32 位 JIT 和 64 位 JIT 分别是 Microsoft 中两个不同团队使用两种不同的代码基实现的。32 位 JIT 是由 CLR 团队开发的，而 64 位 JIT 是由 Visual C++ 团队开发的，而且基于 Visual C++ 代码基。因为 64 位 JIT 是由 C++ 团队开发的，所以它更加注重与 C++ 相关的问题。
双 Thunk 消除
64 位 NGEN 执行的最重要的优化之一就是所谓的双 thunk 消除。这个优化在带 /clr 开关编译的 C++ 代码中通过函数指针或虚拟调用解决了一个转换，这个转换发生在通过托管代码调用托管入口点的时候。(在 /clr:pure 或 /clr:safe 编译代码中不会发生这种转换。)发生这个转换是因为在 callsite 上函数指针和虚拟调用都没有足够的信息可以确定它们调用的是托管入口点 (MEP) 还是非托管入口点 (UEP)。
为了向后兼容，始终选择 UEP。但如果托管 callsite 实际调用的是托管方法呢?在这种情况下，除了初始 thunk 从托管 callsite 进入 UEP 外，还会有一个 thunk 从 UEP 进入目标托管方法。这个托管-托管 thunk 过程通常称为双 thunk。
64 位 NGEN 实现了对“从非托管到托管”的调用(即为反过来对托管代码 thunk 的调用)，从而实现了优化。可以进行一个检查来确定是否是这种情况; 如果是，它就会跳过这两个 thunk，并直接跳到托管代码，如图 2 所示。这样可以节省许多指令，在实际的代码建模基准中，我发现有 5-10% 的提高(在人为测试中，可以看到超过 100% 的性能提高)。
不过有一点需要注意，那就是这个优化只有在位于默认应用程序域时才生效。有一个很好的小规则，那就是记住，默认 AppDomain 通常会获得更好的性能。
C++ Interop
C++ interop 是用于本机托管 interop 的一种技术，它允许标准 C++ 代码带 /clr 开关编译，以便直接调用本机函数，而不用编程人员添加其他任何代码。当使用 /clr 开关时生成的代码是 MSIL(除了少数特例)，并且数据可以是托管或非托管的(由用户指定数据的存放位置)。我倾向认为 C++ interop 是没有人知道的最重要的 .NET 功能。它是真正具有突破性的改革，但要真正了解 C++ interop 的强大之处还需要一定的时间。
在其他与 .NET 兼容的语言中，要与本机代码进行 interop 需要您将本机代码放在一个 DLL 中，并使用 dllimport 调用带有显式 P/Invoke 的函数(或者其他一些与此类似的做法，取决于您使用的语言)。否则就必须使用笨重的 COM interop 访问本机代码。这明显不方便，而且经常会遇到性能比 C++ 差很多的情况。
一般不认为 C++ interop 是 C++ 语言的性能特征，但正如您将看到的，C++ interop 所提供的灵活性和便利性却可以让您借助 CLR 获得更好的性能。
单映像中的本机代码和托管代码
Visual C++ 可以使编程人员(按逐函数方式)有选择地选择哪些函数是托管的，哪些是本机的。 这是通过 #pragma managed 和 #pragma unmanaged 实现的，图 3 显示了其中一个例子。在许多计算量大的任务中，让核心函数进行本机编译而其他代码进行托管编译可以带来很大好处。在单个映像中，C++ 可以将托管代码和本机代码混合一起，通过本机函数调用托管函数(反之亦然)不需要特殊的语法。在这种粒度下，C++ 可以很轻松地控制从托管代码向本机代码的转换，反之亦然。
当从托管代码向本机代码转换(或反向)时，执行的过程要经过由编译器/链接器生成的 thunk。这个 thunk 需要一定代价，编程人员都竭力避免付出这样的代价。有大量工作是在 CLR 中完成的，并且编译器会使转换的成本降到最低，但开发人员也可以通过降低这种转换的频率来帮助降低成本。
图 4 的 A 部分中是一个 C++ 应用程序，它的部分代码 (Z.cpp) 经编译生成 MSIL (/clr)，而其他部分(X.cpp 和 Y.cpp)经编译生成本机代码。在这个程序中，Y.cpp 和 Z.cpp 中有些函数经过来回多次调用。这会导致大量托管/本机转换，从而降低程序的执行速度。
图 4 中的 B 部分显示了如何优化该程序来使托管/本机转换降至最少。其思想是确定常用接口，将它们都移到托管/本机界限的一侧，从而消除所有跨常用接口的转换。使用 Visual C++ 为 interop 提供的工具可以很轻松地完成这项工作。
例如，要从图 4 中的 A 转到 B，只需要用 /clr 开关重新编译 Y.cpp。现在 Y.cpp 被编译为托管代码，从 Z.cpp 调用就不需要有从托管到本机的转换成本。当然，您也需要考虑从 Y.cpp 生成 MSIL 的相关性能代价，并确保这种折衷对应用程序有利。
高性能封送处理
封送处理是托管/本机 interop 中成本最高的方面之一。在 C# 和 Visual Basic .NET 等语言中，封送处理是在调用 P/Invoke 时 CLR 隐式完成的(使用默认封送拆收器或者在实现 IcustomMarshaler 时用自定义封送处理代码完成)。而在 C++ interop 中，编程人员可以在代码中认为合适的地方显式封送处理数据。这样做的好处是编程人员可以一次性将数据封送到本机数据，然后通过多次调用重用数据的封送处理结果，从而均摊封送处理成本。
图 5 显示了带 /clr 开关编译的代码片段。在这段代码中有一个 for 循环，在这个循环中调用本机函数 (GetChar)。在图 6 中，采用 C# 实现相同的代码，并且通过调用 GetChar 来使 CsharpType 类封送处理到 NativeType，如下所示：
以下是引用片段：
class NATIVECODE_API NativeType {
public:
NativeType();
int pos;
int length;
char *theString;
};
在 C++ 中，用户显式使用本机类型，因此不需要隐式封送。这种类型的优化所节省的成本相当大。在这个示例中，C++ 实现比 C# 实现快 18 倍。
具有 .NET 类型的模板和 STL
Visual C++ 2005 中一些比较有趣的新性能特征是具有托管类型(包括 STL/CLI)的模板、与托管代码的全程序优化、延迟加载和确定性终止。Visual C++ .NET 2003 可以在本机类型上为模板生成 MSIL，但不能在该模板中将托管类型作为参数化类型使用。在 Visual C++ 2005 中，这个问题已经得到纠正，模板现在可以将托管类型或非托管类型作为参数。现在，模板的强大功能可以用于在 .NET 中编写的代码了(您还应该看一下 Blitz++ 和 Boost 库所做的工作)。
C++ 标准模板库 (STL) 是库设计中一个重大革新。它可以让您很好地利用容器和算法而不会牺牲性能，这一点已获证实。在 Visual C++ .NET 2003 中，在模板中对托管类型的限制意味着没有托管类型的配套 STL。Visual C++ 2005 中除了具有这种限制外，还引入了 STL/CLI — 一种已证实可处理托管类型的 STL 版本。.NET 中的基类库 (BCL) 最初在 .NET 中引入了容器，但 Visual C++ 小组中的计划是 STL/CLI 的性能会更加优越。如果您想对 STL/CLI 有更多了解，Visual C++ 开发人员中心中有一篇 Stan Lippman 所撰写的优秀文章 STL.NET Primer。
有了 STL/CLI 后，您可以通过 STL 实现您喜欢的所有内容，包括矢量、列表、双端队列、映射、集合以及哈希映射和集合。您还可以获得排序、搜索、集合运算、内积和卷积等算法。STL/CLI 算法的一个惊人之处是可对本机和 STL/CLI 版本使用相同的实现。STL 的良好设计将通过可移植的强大的代码来让每个 C++ 编程人员受益。
确定性帮助性能
由于您可以使用强大的模式和术语库，编写有效的 C++ 变得轻松许多。其中许多模式和术语(包括 Resource Acquisition Is Initialization (RAII))使用 C++ 语言中一个称为确定性终止的功能。它的原则是当一个对象被 delete 操作符删除(对于堆栈分配对象)或处于作用域外(对于堆栈分配对象)时，就会调用该对象的析构函数。确定性终止可以挽救性能，因为一个对象占有资源的时间越长(比它真正需要的长)，性能下降越多，因为其他对象试图获取相同的资源。
使用 CLR 终止程序会导致终止程序代码在对象处于作用域外(假设释放锁的代码是该终止程序)但还没在对象的终止程序上调用终止线程时在某一个位置执行。显然，这样做并不理想，因为当编程人员期望执行终止线程时，它可能不执行。另外，与对象相关的内存直到终止程序执行后才会回收，这样会使程序对内存的要求增加。
在基于 .NET 的代码中，一个有助于避免这种问题的常见术语是 Dispose 模式。要使用它，开发人员需要为他们的类实现一个 Dispose 方法，然后在不再需要对象时调用该方法。当 C++ 编程人员要对对象调用 delete 时，就可以同时在代码中调用这个方法，但即使在 C++ 中，这样也很容易出错且过于繁杂。诸如 C# 等语言添加了“using”构造，它有助于解决后面两个问题，但对于特殊情况，它也会很复杂且容易出错。
相反，RAII 这个 C++ 术语自动获得和释放资源，而且不容易出错，因为编程人员不需要编写额外代码。Visual C++ .NET 2003 不支持堆栈分配 .NET 对象的确定性终止，但在 Visual C++ 2005 中支持这个功能。
在图 7 的上半部分，可以注意到类型为 Socket_t 的对象使用了基于堆栈的语法，并将具有基于堆栈的清除语义。这样，当在第三行产生一个异常时，会出现什么情况呢?对于基于堆栈的语义，会确定性地为 mainSock 运行析构函数，但由于还没在堆栈中创建 backupSock，所以没有对象可以析构。
要编写语义上等同于 C# 的代码有些困难且容易出错; 请参见图 7的下半部分。当然，这个例子很小，但随着这种任务复杂度的增加，出现错误的可能性就会越大。
延迟加载
虽然 .NET Framework 为提高性能而进行了微调，但在启动时加载 CLR 还稍微有些延迟。在许多应用程序中，可能有一些代码路径和方案没有托管代码，特别是当通过 .NET 功能对现有的旧式程序进行改造时。在这些情况下，您的应用程序就应该不会有这种相关的启动延迟。您可以使用 Visual C++ 中现有的功能 — DLL 的延迟加载来解决这个问题。
其思想是只在实际需要使用 DLL 中的某些内容时才加载该 DLL。这种思想也可应用于加载内容为 .NET 程序集的 DLL。通过使用链接器选项 /DELAYLOAD:dll(通过它指定想要延迟加载的 .NET 程序集)，除了可以延迟加载列出的 .NET 程序集外，还可以延迟加载 CLR(如果所有 .NET 程序集都延迟加载)。结果是，应用程序的启动速度可以完全像本机启动那么快，从而消除了托管应用程序最常见的弊端之一。
为什么 dllexport 不能始终适用
使用 __declspec(dllexport) 有它自己的缺陷。当您有两个映射(DLL 或 exe)都为托管映射，但通过 dllexport 而不是通过 #using 公开功能时，dllexport 的问题就会暴露。因为 dllexport 是一个本机构造，所以每次使用 __declspec(dllexport) 跨 DLL 边界调用时，都会先引发从托管到本机的转换，再引发从本机到托管的转换。这样就难以获得很好的性能。
解决这种性能问题的选择很有限。没有简单的“开关”可以立刻让 __declspec(dllexport) 成为对托管代码没有相关 thunk 的构造。推荐的修复办法是将导出的功能包装在一个托管类型(引用或值类/结构)中，导入程序再通过导出 DLL 上的“#using”访问该类型，从而直接访问导出 DLL 中的功能。通过这种更改，当从托管客户端调用这段托管代码时就不需要进行转换。图 8 中对此做了说明，其中 A 部分显示了与使用 __declspec(dllexport) 相关的成本，B 部分显示了使用 #using 和将函数包装在 .NET 类型中所带来的优化。这种方法的一个潜在问题是导出 DLL 的非托管导入程序不能对 DLL 的功能进行 __declspec(dllimport)。这在进行更改之前应该加以考虑。
图 8 的 A 部分显示了使用 __declspec(dllexport) 将托管函数公开给托管代码的转换路径。在 B 部分中，该函数被包装成托管类型，并使用 #using 来访问该函数。与 A 部分中的过程相比，其结果是省去了成本很高的 thunk。
小结
Visual Studio .NET 2002 引入了带有 Visual C++ 的 .NET Framework 已有很长的时间。C++ 使得编程人员编写高性能托管代码具有很大的灵活性，而且都是按 C++ 编程人员很自然的方式工作的。有许多语言可用于进行 .NET 编程; 如果您想获得最大的性能，则 Visual C++ 是显而易见的选择。
Kang Su Gatlin 是 Microsoft Visual C++ 团队的程序经理，他的大部分工作时间都在尝试寻找可让程序运行更快的系统方式。在到 Microsoft 工作之前，他从事高性能和网格计算。

Technorati 标签: C++