http://document.pcpop.com/0/84/84261.shtml第1页：前言：迟到的64位测试 K8尴尬的一年半 AMD在2003年秋天发布了他们的Athlon64系列处理器，将PC带入了64位运算的时代，从而揭开了64位运算的崭新一幕。 然而，这一幕却似乎有些遗憾在里面，64位的舞台已经搭建完毕，但是我们却不见舞台上的演员出现，让大家看到了一场没有演员的表演。 Athlon64的三大尴尬： 1.没有操作系统支持。虽然微软在Athlon64发布的时候临时推出了一个操作系统，但是这个操作系统是个测试版，而且距最终的发售版本差的有些远。 2.没有应用软件支持。在操作系统尚不完备的时候，自然是没有Windows下应用程序的支持了，不要说真正能够实用的应用软件，甚至连一些测试64位性能的软件也是凤毛麟角般的少见。 3.游戏是雷声大雨点小。对于个人用户，游戏是计算机的非常重要的功能，在Athlon64发布的时候，已经有多家游戏公司表示将推出64位的游戏，其中包括我们熟悉的UT2004以及后来的Farcry。然而，我们却没有见到过任何一个公司如约推出64位游戏，这倒不能怪这些游戏厂商，因为谁也不会在一个没有稳定的操作系统上花很大精力做一个游戏的。 

第2页：不凭借64位也能干过P4，A64成功之本 但是，我们并没有看到我们非常喜欢的Athlon64系列的处理器带着悲伤离开，而是在处理器市场收到了广大消费者的喜爱。可以说Athlon64最终还是非常成功的，只不过这一成功并非单纯凭借其64位性能，那么它凭借的是什么呢？ Athlon64的成功之本： 1.Athlon64系列处理器支持32位运算。这可以说是最重要一点，在没有64位运行环境和软件的情况下，消费者可以在目前的操作系统和软件上体验到Athlon64很好的性能。 2.Athlon64系列还支持其他的64位环境。出了Windows，Athlon64系列以及它的同胞兄弟Opteron都支持其他的64位操作系统，比如Linux，FreeBSD等操作系统，这些系统由于源代码开放，所以安全性和效率非常高，是服务器第一选择的操作系统。 3.Athlon64拥有出色的性能。从2003年秋天到现在，Athlon64大家已经接触了有一年半的时间了。在这一年半的时间里，我们看到了各种Athlon64的测试，并且也亲身体验了Athlon 64的性能，Athlon64性能可以说让我们非常满意，无论是游戏性能或者是日常的办公应用，Athlon64都表现出了非常高的水平，就目前而言，Athlon 64 FX55仍然是拥有最好性能的处理器。

第5页：熬啊熬啊熬，终于熬到了微软发布XP X64 在发布之后的很长的一段时间内，微软对于Windows XP 64位版本一直保持着不温不火的态度。在很长一段时间内，WindowsXP 64位版本一直保持着“Beta”的版本号，离成熟与普及还相差很远。 直到2005年，WindowsXP 64位版本再次引起了大家的注意，这主要是因为微软在2005年年初突然放出了Windows XP Professional x64 Edition RC1，RC就是Release Candidate（候选版本）的简称。 RC版本的释放，代表着距离这款操作系统最终的发布已经不远了，人们开始再次关注起这个几乎被大家忘掉的操作系统。 没有等多长时间，Windows XP Professional x64 Edition RC2也发布了，按照微软的习惯来讲，通常是不会放出RC3的，RC2的发布说明距离正式版本的时间已经越来越接近了。果然，微软终于在近期放出了Windows XP Professional x64 Edition RTM（Release To Manufacture）版本，PCPOP评测室有幸在第一时间拿到了这个版本。

第7页：技术解析：理解64位从64位指令开始 我们都知道，处理器所处理的普通指令一般由操作码（OP Code）和操作数（Operand）组成。其中操作数可以是等待处理的数据，也可以是待处理数据的内存地址。而操作码则描述将要对操作数进行何种处理。 需要强调的是，通常所说的64位指令，并不是指指令的全长或操作码的长度为64位，而是指操作数所能达到的最大位数为64位。通过下面的图示，我们可以很好地理解64位指令和64位处理器的本质。

由于操作数一般需要存放在通用寄存器中，因此64位处理器通用寄存器的尺寸也必须是64位。这样我们就很容易理解K8处理器里通用寄存器结构的上半部分（指RAX-RSP部分，下半部分我们后边再提）。如下图所示：

第8页：技术解析：寄存器和数据类型 我们知道：整数、地址、指令指针和浮点数据是按照数据形式来划分的，CPU所要处理的3种主要数据类型。此外我们还可以根据数据需要CPU进行处理的类型，来将它们分为标量数据和矢量数据两大类。 通常我们把需要CPU进行不同处理的单个数据称为标量数据（Scala Data）。标量数据既可以是整数数据，也可以是浮点数据。其中整数标量数据的存放区一般为通用寄存器（GPR），浮点标量数据的存放区一般为浮点寄存器（FPR）。 与标量数据相对的是矢量数据（Vector Data）。所谓矢量数据就是指一列需要由处理器作相同处理的数据集合。比如处理器在做MP3编码的过程中，需要对内存中的音频文件里的各字节数据作相同的MP3编码操作。那么通常使用MMX或SSE这类单指令多数据流(SIMD)指令，将数个字节打包为一组矢量数据，存放在MMX或SSE寄存器中，再送往相应的功能单元进行统一操作。 和标量数据一样，这些矢量数据既可以是整数数据，也可以是浮点数据。矢量数据以封包的形式批量存放在MMX（对于使用MMX、3DNow！进行操作的数据而言）和XMM（对于使用SSE、SSE2进行操作的数据而言）寄存器中。 通过下面的图，我们可以更好地了解标量数据和矢量数据的区别：

以下，我们整理了标量数据和矢量数据在X86-32位处理器以及AMD的X86-64处理器中所用寄存器的具体区别如下表：

实际上，MMX和XMM通过寄存器映射的方法，也可以参与标量浮点数据的存储。同时数据类型也远不止整数、浮点这两类基本数据类型，还包括有指令指针数据、BCD数据，位数据等。要把这些情况一一说清，显然不是一两篇文章能解决得了问题的。 幸好，这些省略的部分与我们的结论并没有影响，因此我们叙述时使用了简化的措施。需要更详细完整的资料，您可以参考Intel的IA32以及AMD的X86-64架构编程指导书。 从上表我们可以看见，K8的64位扩展部分似乎仅对于整数、地址数据有效。对浮点和向量数据则仍然保持原样。 经过上面的分析，我们似乎可以得出这样的结论，那就是：我们能从K8向64位的扩展所获得的好处，只不过是可以在同样一条指令中，处理更大数值的整数数值以及管理空间更大的内存区域而已。而在32位的情况下，由于通用寄存器只能容纳最大32位的数据，因此显然要花费更多条指令对尺寸超过32位的数据进行处理。 这种改进对服务器、科学计算这样的领域虽然具有一定的意义，但显然并不是普通家用环境急需的改进。试问在近期普通应用中，有多少情况下会用到超过232这样大的整数数值和超过4GB的内存空间呢？ 然而，如果你因此低估了K8和X86-64指令集的实力，那就大错特错了。

第9页：技术解析：寄存器体系的变革 我们都知道，X86指令集本身属于一种复杂指令集（CISC）。长期以来，使用X86指令集的处理器架构一直沿用寄存器结构。相比那些使用精简指令集（RISC）的处理器架构来说，由于程序可见的寄存器数量较少，因此造成传输延迟，性能以及流水线工作效率相对落后，从而给X86架构处理器的表现造成了影响。同时程序和编译器的优化难度也较大。 虽然近代的X86处理器中都增加了许多程序不可见的内部寄存器，并通过寄存器换名（Register Rename）技术变相地增大通用寄存器的数量，来弥补这一不足。然而这种措施由于只能通过处理器的硬件控制来实施，程序员无法根据需要来，灵活控制实际的寄存器使用状况，显然不如直接增加可见的通用寄存器来的有效。 而K8针对上述问题作出了改良。处理器在64位状态下工作时，增加了大量的程序员可见寄存器以供编程者使用，如下图：

可以说，这些额外增加的寄存器（我们姑且称之为“寄存器扩展“吧），才是真正能为桌面用户带来的好处之所在！ 不过，尽管如此，我们也只能在K8的64位模式下，才能全部用到这些多出来的寄存器扩展资源（紫色部分的寄存器）。因为为了兼容以往的X86指令，K8所用的X86-64指令集将其所支持的指令分成了如下表所示的数个部分：

如上表所见，前面我们所说到的令人激动的寄存器扩展功能，并不是“即插即用“的。它需要我们将操作系统向64位转换，同时重新按64位的编程规范编译应用程序。在其它模式下，我们根本无法享受到这些好处。

我们看到，在这个测试中，64位系统体现出了非常好的性能，64位的程序能够比32位的程序成绩高30％以上。 同时我们注意到，在32位环境下运行的测试，成绩非常低，这起初让我以为是测试环境出了什么问题，但是后来通过3DMark检验，发现32位的系统并没有什么问题，在这个测试中仍然是这个成绩。 作为我们最为关心的项目，3D测试中我们看到64位的优势还是很大的，这样的情况大大增强了我们对于64位系统的信心，因为我们几乎可以预料到在全面64位化的时候，所有游戏的帧速率将提高30％，这是多么美好啊。

第11页：媒体压缩性能测试——DivX 5.03压缩 接下来我们看看DivX Encorder这个测试软件，这个软件的主要作用是将视频文件压缩成为MPEG－4视频，采用的编码方式是Divx 5.03。 这个程序是一个基于命令行的程序，需要用Windows的命令行程序进入。测试的基准是看压缩过程需要的时间，时间越短的性能越好。

2

3

4

DivX压缩的这个项目也是同样的重要，因为这是一个非常考验处理器性能的应用。在这个测试中，我们感受到了WinXP Pro X64的威力，在这个操作系统下，无论是采用32位的程序还是64位的程序，都有非常好的表现，甚至在32位程序运行的时候效率还要好一些。 不同的操作系统做同一件事情，效率能够相差一倍，这样的差距真的是非常大了。由此可见，WinXP X64版的性能还是非常令人满意的。 如果让我们注意一下具体的各个部分的情况，又能发现一些有意思的事情： 对于IO部分，操作系统对于成绩影响比较大，采用64位操作系统的性能要好。 对于编码压缩，程序的版本影响较大，64位的程序的性能要明显好于两个32位的程序。

第12页：文本压缩测试——Mini-GZIP 第三个程序名叫Mini-GZIP，这是一个压缩工具，它采用的核心算法是ZLIB算法，这个软件的作用就是将文件进行压缩。 在这个软件的测试中，是将一个25MB的文本文件压缩，在这个过程中记录所需要的时间，时间越短性能越好。 在这个压缩程序的测试中，我们看到在纯64位环境下的性能仍然是最好的，而且是大幅领先于另外的两个程序。不过，我们在这个测试中发现，在纯32位模式下的成绩要好于在64位环境下使用兼容模式运行32位程序的成绩。

第13页：加密算法测试——RSA 这也是一个测试软件，这个软件的主要作用是采用RSA加密算法，对文件进行加密。同样的，这个软件也需要命令行方式执行。

2