更多的内存更好的性能Windows64位计算的世界.DOC

1、更多的内存更好的性能 Windows 64 位计算的世界 今天， 64 位计算正在逐步取代 32 位计算，并且，这个转换的过程会对当前软件的形式带来巨大的冲击。其中，转换需要移植相关的应用程序及重写系统软件，这当中还包括操作系统等等。在本文中，将主要探讨 64 位软件世界中的主角 -64 位 Windows 及 64 位的通用语言运行时库（ CLR）的结构，另外，还将涉及移植到 64 位平台的种种有利之处。 当 64 位处理器面世之后，它们也存在一个逐渐被接受的过程，主要是因为缺乏相关软件的支持。为了利用 64 位处理器的特性，软件也必须 重新构建 -这可不是一晚上就能搞定的事情，不管怎样，近

2、来由于软件与硬件开发商的共同努力， 64 位处理器的发展势头已越来越快。 比如说，直到去年的早些时候， Intel 和 AMD 的 64 位处理器才逐渐出现在人们的视野之中，最开始， Intel 的 Itanium 处理器基于 IA-64 架构，而 AMD 的 Opteron 及 Athlon64 基于 x86-64 架构。此外，在去年也出现了一些其他的变化，首先， AMD 在 64 位处理器销售上，表现出一个领导者的姿态；其次，惠普也开始接受了 AMD 的处理器，并推出了基于AMD Opteron 的 HP ProLiant 服务器；最后， Intel 也对 x86-64 架构妥协了，宣布以

3、 EM64T（ Extended Memory 64 Technology）的名称推出自己的 x86-64 处理器。 Microsoft Windows 的 64 位版本 在软件方面， Microsoft 已经研发出为桌面电脑准备的 64 位 Windows-Windows XP Professional x64 Edition（ http:/ Windows Server 2003 x64 Edition（ http:/ 64 位 Windows 与 32 位 Windows 相比，其明显优势在于性能方面的提高及可伸缩性（因为 64 位处理器可在一个时钟周期处理更多的数据）、更快的速度、更精

4、确的数字计算、及可访问更多的内存。可访问更多的内存意味着在单个计算机上， 64 位 CPU可比 32 位 CPU支持更 多的用户，正是因为单个计算机与以往相比可支持更多的用户及运行更多的程序，对一个部门组织来说，它可以减少服务器的数量，以达到降低信息化总成本的目的。 话说回来， 64 位 Windows 想要获得市场接受，很大程度上还取决于对 32 位程序的支持程度，因此，程序从 32 位移植到 64 位，还需要一定的时间，在此期间，还必须可同时运行 32 位及 64 位程序， 64 位的 Windows 对此的支持是 -广为人知的 “WOW64“子系统。 WOW64 WOW64 是 “Win

5、dows 32 on Windows 64“的简称，它在系统 层中另提供了一层，以支持老式的 32位程序。首先，在 64位版本的 Windows中，系统文件不会全放在 WindowsSystem32文件夹中，而是分开放在两个文件夹中，以区分 32 位程序与 64 位程序。 WOW64 子系统截取 32 位程序对系统文件的调用，并重定向到 WindowsSysWow64 文件夹，见图 1。如果是64 位程序的调用，则会直接转到 WindowsSystem32 文件夹。此处值得注意的是， Microsoft仍保留了 System32 文件夹，其主要用于保存 64 位系统文件。图 2 是运行着 Wi

6、ndows Server 2003 x64 Edition 系统的一个截图，重点标出了 Program Files 文件夹，其用于存储 64 位程序，而 Program Files(x86)用于存储传统的 32 位程序。 图 1：文件系统重定向 图 2：运行 Windows Server 2003 x64 Edition 的系统 其次， WOW64 子系统也提供了对注册表访问的重定向，见图 3。如果是 32 位程序，那么 WOW64将会截取对 HKLMSoftware访问，并重定向到 HKLMSoftwareWow6432Node；如果是 64 位程序，就直接到 HKLMSoftware。图

7、4 是一个 Windows 2003 Server x64 Edition系统上的注册表，说 明了 Wow6432Node。 图 3：注册表重定向 图 4： Wow6432Node 尽管对 32 位应用程序而言，兼容性的目 标是达到了，但对于驱动程序而言，却不是这样； 64 位的 Windows 对所有硬件都要求本地类型的 64 位驱动程序。 64 位通用语言运行时库（ CLR） 为了让 64 位平台得到更大范围的接受，必须在更大的范围内支持开发者可用的工具及开发平台， Microsoft 对此的做法是，在其自己的核心开发平台 - .NET Framework 上，增加64 位支持。 .NET

8、 Framework 2.0 现在已经可以单独下载或从 Visual Studio.NET 2005 中得到（与Visual Studio.NET 2005 一起提供的版本提供了开发 64 位程序的平台），而且它有两个版本，一个为 32 位，另一个为 64 位（ http:/ updates/default.aspx），也就是说，在 64 位的 Windows 上，有通用语言运行时库的两份拷贝。32 位版本的 .NET Framework 在文件夹 WindowsMicrosoft.NETFramework 中，而 64 位版本的在 WindowsMicrosoft.NETFramework6

9、4 文件夹 中，参见图 5。对此两个版本的Framework 的配置选项也在 “管理工具 “中分别列出，见图 6。 图 5： .NET Framework 32 位版本在 WindowsMicrosoft.NETFramework 文件夹中，而 64 位版本在 WindowsMicrosoft.NETFramework64 文件夹中 图 6：管理工具菜单 为什么要有两个 Framework呢？其实，把源代码编译为 MSIL中间语言代码的一个好处，就是可以充分照顾到各种硬件平台相关的细节。但在这种情况下，还必须考虑一些其他的因素，如： PInvoke 和 Interop，这些都是需要被特殊处理的

10、；而使用 Visual C+ .NET，也很容易创建程序集，其包含了 托管与非托管的代码，这种程序集被称为 “混合模式 “程序集或“IJW（ It Just Works） “程序集，不论是哪种情况，都涉及到平台相关代码，因此，就需要两个 Framework，每一个都是针对于特定的平台。正是因为此， Microsoft 发布了两个版本的Framework。请参见图 7 所示的全局程序集缓存（ GAC），以加深了解，图中需重点注意的是 “Processor Architecture（处理器架构） “，有三种类型 -x86、 AMD64 和 MSIL，其中， AMD64只在运行 64 位 Windo

11、ws 的机器上显示；在 运行基于 Intel Itanium 处理器的系统中，处理器架构一栏中， AMD64 将会由 Itanium 取代，此处，处理器架构指明了程序集构建的特定平台。 图 7：全局程序集缓存（ GAC） 但是，在此处只有一个程序集会被编译为 MSIL，因为 MSIL 对处理器架构来说是中立的，同一程序集可以不作任何修改而运行于 x86 或 AMD64 平台上。而这些 MSIL 程序集也被称作 “可移植程序集 “，例如，在图 7 中的 System.xml只有一个版本，其处理器架构为 MSIL。 然而，针对特定处理器架构构建的程序集需要分开存放，如 AMD64 架构的程序集或

12、x86 架构的程序集，这些程序集通常称为 “特定平台程序集 “，举例来说，请看图 7 中的System.EnterpriseServices 程序集，就有 AMD64 与 x86 两个版本。 Visual C+ .NET 2005 开发小组已经竭尽全力提供了尽可能多的基于 MSIL 的程序集，所以有时候只有一个版本。 但是，在某些情况中，有必要重新编写代码以利用 COM Interop或特定平台的某些功能 -如指针大小。这些程序集不会出现在全局程序集缓存的特定平台栏中。 实际上，为在内部分开存放这些程序集，是把它们组织成不同的文件夹，图 8 在命令行中显示了 WindowsAssembly 文

13、件夹的情况，而表 1 则描述了这些文件夹的相关用途。 图 8：命令行中显示的 WindowsAssembly 文件夹 文件夹 描述 GAC 存储 .NET Framework 1.0/1.1 程序集 GAC_32 存储使用 .NET Framework 2.0 构建的 32 位程序集 GAC_64 存储使用 .NET Framework 2.0 构建的 64 位程序集 GAC_MSIL 存储可移植程序集；即那些处理器架构表示为 MSIL 的程序集 表 1： GAC 的组织结构 通用语言运行时库（ CLR）的变化 CLR 已经作了内部的修改以支持 64 位 计算，在很大程度上，此修改涉及到代码生

14、成、垃圾回收、例外处理、和调试等等。 代码生成。 64 位版本的 CLR 需支持 64 位本地应用程序的开发，这通常意味着对每一个新平台，都必须重新构建一个 Just-In-Time（ JIT）编译器，也就是大家所看到的 IA64 与x64 平台。 垃圾回收。 64 位处理器可寻址更大的内存，突破了 32 位系统中存在的 4GB内存界限。因此，垃圾回收机制也必须作相应修改，以支持更大的内存。 例外处理。在对最终用户的使用方法保持不变的前提下， 64 位系统的例外处理已经彻底修改并重 写。 调试。调试器依赖于代码生成与例外处理子系统，因为一旦这两个子系统变了，调试器也必须跟着改变。 开发工具 在

15、 Visual Studio 2005 中， Visual C+ .NET、 Visual C#、 Visual Basic .NET 已经支持 64位应用程序的开发，而作为 Visual Studio 2005 另一个组成部分的 Visual J#却不支持。图 9描述了在 Visual Studio 2005 中对不同语言的支持，及这些托管语言所支持的平台环境。 图 9： Visual Studio 2005 中的语言及平台支持 Visual Studio 2005 集成开发工具仍会作为 32 位程序发布，并在 WOW64 系统下运行。大多数在 32 位平台上具有的功能，在 64 位平台上同

16、样也具有，但要注意的是，此处没有 “编辑并继续（ Edit and Continue） “功能。 除了 Visual Studio 2005， Windows Platform SDK 同样也提供了 64 位编译器工具集，其中包含了一个可用于开发 64 位应用程序的 Visual C+编译器。 预防性措施 在开发 64 位本地应用程序之前，有必要弄清楚：我们到底应采取哪些步骤，以保证今天的程序将来可移植到 64 位？ 在此，可参考以下一些预防性措施或使用一些工具，例如， Visual C+编译器支持 /Wp64选项，以探测当前代码中存在的潜在移植性问题。 另外，在 Visual Studio

17、2005 的集成开发环境中，还有一个类似的工具 -FxCop，通 过在FxCop 中加入一些规则，便可在编译时探测到移植性问题。 在托管语言方面，以下情况涉及到移植性问题： 涉及 COM Interop 与平台调用的 Interop 相关代码：本地 64 位程序不能加载 32位 COM DLL，这就是说，一个 64 位的进程不能转变为 32 位代码，并在同一进程中成为一个 32 位DLL 的宿主程序；不同处理器架构间的 Interop 也不能在同一进程中做到这一点。因此，当一个 64 位程序必须要调用 COM DLL 时，此 COM DLL 最好也是 64 位的。 在许多情况中，这些 COM

18、DLL 是第 三方代码，所以你可能没有源代码。如果这样的话，程序就必须针对 x86 架构重新构建，并且运行于 WOW64 子系统中。还有一个解决的办法，在另一个单独的 32 位进程中加载此 32 位的 DLL，由 64 位程序对此进行 RPC 调用。 浮点数的相等比较。不能保证同一 IL 中间语言代码在 32 位与 64 位平台上有相同的结果，因此，推荐不要直接进行浮点数的相等比较。浮点数在 64 位计算机上的表示法基于IEEE-754 标准，其允许差分计算，这会对那些对精度要求非常高的金融程序与图形程序带来很大的影响，必须重新设计算法以应对此问题。有关更 多信息，请参考：http:/ 使用

19、StructLayout 属性对结构数据排列方式的显式控制。属性 StructLayout 可应用于结构和类，当它被显式地指定时，必须精确地控制非托管内存中对象的每一个成员的位置。相对于 32 位平台，因为数据类型长度有所变化，所以结构的打包也有所不同，因此，必须避免显式地控制结构的排列方式。 对数字的位操作。 C#提供了位操作符，包括了 AND、 OR、左移位和右移位操作符。对数 据类型的位操作，在 32 位与 64 位计算机上会有所变化，这是因为平台间数据类型的内部表示方法会有所不同。 自定义串行化。 .NET Framework 对串行化提供了两个选项 -通过使用 Serializabl

20、e 属性实现自动串行化，或对类型实现 ISerializable 接口达到自定义串行化的目的。当使用 .NET Freamwork 提供的最基本的串行化机制时，不会发生什么问题，然而，当通过 ISerializable实现自定义串行化时，得出的结果会因为 32 位与 64 位平台而有所不同，具体依赖于为实现自定义串行化 而采用的方法。 当然，也许程序中会多次用到涉及上述的功能，在这种情况下，必须分别构建和测试 32 位与 64 位版本的程序。 使用 Visual Studio 2005 进行开发 回头再看， Visual Studio 2005 可支持 64 位应用程序的开发，其所支持的平台如

21、表 2 中所示。 平台 描述 AnyCPU 生成不依赖于特定平台的程序集，通常称为 “可移植程序集 “ x86 生成针对 x86 平台的 32 位程序集 x64 生成针对 x64 平台的 64 位程序集 Itanium 生成针对 Itanium 平台的 64 位程 序集 表 2：针对不同平台， Visual Studio 2005 所支持的 64 位程序开发 在编译程序期间，可在 “工程 “的 “属性页 “中设置目标平台，属性页包括一个构建栏，可以让你指定相关的平台。例如在图 10 中， C#和 VB.NET 的编译器选项为 “/platform“，在VB.NET 中，也可在 “高级编译器设置

22、 “对话框中找到同样的选项。图 11 中所示的目标 CPU下拉框允许设置程序所需的特定 CPU类型。 图 10：编译器目标平台可选项 图 11：目标 CPU下拉框 当然，使用特定的设置依赖于特定的情况： AnyCPU选项生成平台无关程序集，这也是集成开发环境（ IDE）的默认设置。一个通过 AnyCPU 选项编译的程序集可毫无 问题地运行在 x86、 x64 及 Itanium 平台上，而生成的程序集基于 PE32 格式（ PE32 是所有 EXE 及 DLL 用到的格式）。 x86 选项用于生成特定于 32 位 Intel x86 兼容处理器平台的代码。所生成的程序集同样也基于 PE32 格

23、式，可运行于 WOW64 子系统中。 x64 选项用于生成特定于 x86 处理器架构的 64 位本地程序的代码。所生成的程序集基于 PE32 +格式（其为现有 PE32 格式的扩展），只能运行在 64 位 x64 架构的计算机上。 Itanium 选项用于生成特定于 Itanium（ IA-64）处理器架构的 64 位本地程序的代码。所生成的程序集同样也基于 PE32 +格式，只能运行在基于 64 位 Itanium 的计算机上。 也许开发出来的程序不必运行在所有的平台上，因此，就不必构建成一个平台无关的程序，这样的话，开发过程中就能充分利用诸如 #define、 #if 之类的预编译指令，可

24、以用这些预编译指令带上条件编译常量，来包装针对特定目标平台的代码。 以下是推荐的条件编译常量： _AMD64_ 用于针对 AMD64 平台的代码 _IA64_ 用于针对 IA64 平台的代码 _WIN64_ 用于指定任一 64 位 Windows 平台代码 加载一个 .NET 可执行文件 在编译生成可执行文件时，指定的编译器选项会被嵌入到所生成 PE32 或 PE32+可执行文件中。而 PE32+格式是 PE32 格式的扩展，含有关于机器类型的更多信息。 在 PE32 中， CLR 头包括一些额外的标志，如： ILOnly 和 32BitRequired， ILOnly 只出现在当平台被设置为

25、 AnyCPU时，而 32BitRequired 出现在平台被设置为 x86 时，而当平台被设置为 x64 或 Itanium 时 ，就会生成嵌入了机器相关信息的可执行文件。 OS Loader（操作系统加载器）根据这些设置来加载相应的可执行文件，图 12 演示了OS Loader 加载可执行文件时的控制流程。 图 12： OS Loader（操作系统加载器）加载可执行文件的流程 当 OS Loader 发现可执行文件为 PE32 +时，会把它作 为一个 64 位进程加载；如果不是，接下来会检查 ILOnly 标志，如果也没有，则会使用 WOW64 子系统把它作为一个 32位可执行文件加载。

26、当设置了 ILOnly 标志时，会进一步地检查是否 32BitRequired 标志也设置了，如果是，也会被 WOW64 子系统加载，否则，将重映像为 PE32+，并作为一个 64 位程序加载。 那程序速度更快了吗？ 大多数人在想到 64 位计算时都会问同样一个问题： 64 位程序与 32 位程序相比，是不是更快一些呢？这也许是关于 64 位技术的一个误区，对此的回答是： “也许吧 “。这样回答的原 因是，程序的速度或者说性能，基于许多的因素，不可能立马下结论表示 64 位程序一定就更快。 64 位计算的好处在于，它打开了更先进软件设计的大门 -这些软件能充分利用64 位处理器访问更大的内存、

27、在单个时钟周期能处理更多的数据，相对于类似的 32 位程序，新生的 64 位程序可表现出惊人的效果。 业界的 64 位趋势 许多 Windows 软件开发商，现在已开始发布基于 64 位 Windows 的软件产品了。 AMD 发布了一个 Windows 上的性能分析器 -AMD Code Analyst ，参见http:/ us-en/Processors/DevelopWithAMD/0,30_2252_869_3604,00.html InstallShield 10.5 已支持 64 位 程 序 的 安 装 。 参 见http:/ Compuware 发布 了 名为 “DevPartn

28、er64“ 的 64 位 DevPartner Studio 。参见http:/puware .com/products/devpartner/64.htm 针对 AMD64 平台的 Java 2 Platform Standard Edition 5.0 (J2SE)现在也可以获取了。参见http:/ =JSC&TransactionId=noreg 硬件生产商也为它们的产品发布了 64 位的驱动程序。此处可找到一个完整的 列表：http:/ DevelopWithAMD/0,30_2252_875_10454,00.html；其中NVIDIA 已经为它的全系列 GPU与 nForce 4

29、芯片组发布了 64 位驱动程序。 游戏总是会用到最新最强大的硬件，例如 Unreal Tournament (http:/ us-en/Processors/ProductInformation/ 0,30_118_10220_9486%5E962175301,00 .html)、 Far Cry (http:/ /us-en/Processors/DevelopWithAMD/ 0,30_2252_875_10543,00.html)、和Shadow Ops: Red Mercury (http:/ ComputingSolutions/0,30_288_11054_ 11705,00.html)。 (Shadow Ops 的 64 位增强版本http:/ 总而言之， 64 位 Windows 将会带领我们进入一个崭新的 64 计算时代，让我们一起期望这一天的早日到来。