不懈的斗士（AMD处理器）

轩辕砍刀

3DS Max: 4.26

　　的确，我们知道3D Max 5 已经上市，并且有一段时间了。但我们还是想继续使用我们最喜欢的benchmark测试之一（3DS Max: 4.26），因为它是一个纯CPU（SMP对称多处理系统）的benchmark测试，在这项测试中，还会对内存子系统进行测试。这项测试完全独立于硬盘和图像卡，所以你可以将这些结果与3D 渲染测试结果进行对比。

　　我们使用SPECapc 3DS MAX R4.2 测试了构架场景。这项测试中有一个移动的镜头，通过这个镜头来展示一个复杂的建筑，或者说一个虚拟的几何相似模型。这个复杂的场景拥有不少于600，000个多边形以及7条光线。同时还启动了光线追踪和雾化效果。在500x300分辨率的时候，每秒大约有20－22帧被渲染到虚拟帧缓存中（内存）。



　　简直可以称得上游戏艺术家了，1.8GHz Opteron系统比2.8GHz使用了超线程的Pentium 4 Xeon系统快了至少20％，这个结果让人耳目一新！



　　猿猴模拟，一个典型的游戏角色渲染对于光线的使用非常的多，总共使用了不少于44条不同的光资源。这个场景还使用了相当复杂的"反转运动学"（complicated inverse kinematics）特性：通过骨骼操纵来控制面部模拟，通过参数配线来移动手指。Maxscript（宏语言）被使用来控制特定的移动。多边形的总数相对来说偏低，只有26，000个。Motion blur，是一个针对SSE-2 进行了优化的功能，通过在6条通道中渲染场景来实现。在320x240分辨率的时候，能达到20到25帧的渲染速度。



　　双Opteron系统的结果与双Xeon 2.8GHz系统的结果相同。猿猴模拟的benchmark测试的要求并不是太高。
POV-Ray 3.5


　　POV-Ray是一个免费的可以在windows,Linux,MacOS和更多平台上使用的光线追踪器。POV-Ray 可以被用来产生相当不错的光线追踪场景。下面是一些POV-Ray的文档：

　　光线追踪是一项渲染技术，这项技术通过模拟现实世界中光线传播的轨迹来产生一副场景的图像。不过它是倒着来做这项工作的。在现实世界中，光线是从光源发射出来，然后照亮物体。光线在物体表面反射或者穿过透明的物体。反射后的光线射中我们的眼睛或者一个摄像机镜头。因为绝大多数的光线从来不会击中一个在它旁边的观察者，所以要追踪一个场景的光线可能需要永远的时间。

　　像POV-Ray这样的光线追踪程序，会通过生成的模拟镜头来向后追踪光线，直到进入这个场景。用户可以设定镜头的位置，光源和物体，以及物体的表面纹理等属性，物体的内部（如果是透明物体）以及任何的大气媒体，如雾和火。

　　对于最终图像中的每一个像素，镜头都会射出一条或多条观察光线（viewing rays），到这个场景中，来看这些光线是否与场景中的任务物体相交叉。这些观察光线是从观察者（这里由镜头来代替）发出的，然后穿过观察窗口（这里代表了最终的图像）。――――个人认为这个也可要可不要。



　　测试场景

　　要对POV-Ray进行benchmark测试，我们使用了标准benchmark场景（benchmark.pov），以及标准的benchmark设置（benchmark.ini）。



　　除了1GHz的时钟频率的差距，Opteron系统相对于2.8GHz P4 Xeon有略微的优势。这是一个单线程的benchmark测试，所以只有一个CPU能够被利用。我们使用了POV-Ray 网站的标准二进制库（binary）发行版（运行在Linux平台上）。1.05 GHz UltraSPARC III系统是最慢的，所花的时间为Opteron系统的两倍。可能由于这项测试只能利用1颗CPU，UltraSPARC III系统就处在不利的地位，因为SunFire 6800使用了12颗CPU，并且很大程度上取决于运行软件对于它的优化的程度。

　　最快的CPU，却是运行在低50MHz频率上的1GHz的Itanium II，它的性能表现超过了1.8GHz的Opteron几乎3倍。请注意测试结果并不是由我们得出的，我们也不能证实结果的准确性。根据benchmark测试的细节，Itanium II binary 是采用Intel C++ 7.0来编译的。我们已经看到不少现实世界的benchmark测试软件，那么用一个综合的benchmark软件来分析对Opteron核心所作的微构架上的改进会有什么结果呢？以及我们能从x86-64构架上看到什么结果呢？
核心的改进


　　为了分析CPU核心能够达到什么样的性能，需要benchmark软件完全或者大部分依靠CPU核心，也就是说，性能能够随着时钟频率线形增长。所有这些需要的只是一个很好的针对on-die cache 进行测试的benchmark软件，因为cache 速度线性地随着时钟频率上升。

　　为了进行这项测试，我们测试了一些相对简单的C程序，在Linux下使用GCC 3.2进行了编译，大多数的L2 cache 命中率都很不错。为了考察x86-64代码（带有同样的64位寄存器）所带来的效果，我们也采用与32位版本进行了相同优化的用GCC编译的x86-64代码。对于x86-32版本，我们使用了相同的二进制库（binary），这主要是为了简便，不过GCC binary从整体上说要比其他的快一些，即使是和Intel的带有Pentium 4优化的Linux C 编译器相比。

　　"Life" （生命）性能测试就是实施Conway's Game of Life（单元自动计算程序"Cellular Automata"的一部分）的过程，这是一个很不错的纯整数运算的benchmark测试，这很适合教授算法和代码优化，因为它可以通过许多不同的方式来编写。其中主要的"life"benchmark拥有一个有限尺寸的板（board），但有两种变化，一种是板上产生物品的数量较少（很分散），另一种板上产生物品的数量较多（很密集）。第二种算法使用了hash函数来模拟一个尺寸无限大的板，这样的话，整体上就会慢一些，不过性能更能随着产生的数量线形增长。

　　FFT benchmark是从伟大的Java benchmark comparison suite（benchmark对比软件包）测试中的Java/C 测试演变而来的。这项测试进行向前的一维的（one-dimensional）转换N个复杂的数字。这个"核心"测试了复杂的算法，非－常量内存参考和三角形函数。

　　在这两个benchmark测试中，一定数量的经过排列的尺寸以及复杂的尺寸被进行对比，而且活动数据的大小达到了200KB，相关的性能常常就在小尺寸和大尺寸之间游动。这些尺寸被故意限制在一定范围内，来保证缓存命中率在足够高的水平，这样CPU核心设计和软件优化间的细微差别就能被更好的显示出来。这些benchmark软件和我们三年前的binaries vs byte-codes（二进制对字节码）benchmark几乎一摸一样。他们都按照获取最大性能的原则来编译的。



　　Opteron系统的得分与Pentium 4系统的得分很接近。虽然时钟频率上有着巨大差异，不过x86-64构架的Opteron系统得分竟然更低，这还是让人觉得有些吃惊。为什么会得到这样的结果还不十分清楚，可能由额外的寄存器带来优化起到了反作用，也有可能x86-64版本的Opteron处理器更适合处理长循环（loop），而对运行时间较短的loop效果不太有效。



　　这项benchmark测试使用了与轻量级测试相同的代码，不过使用了不同的数据。Athlon、32位 Opteron和Pentium 4之间的差别还是和以前一样，唯一和以前不同的就是x86-64优化提高最后的得分（并且提高了相当的比例）。当使用了更多的数据的时候，循环就会运行得更久，这暗示着"循环的解开（loop-unrolling）"是取得结果得主要因素。



　　这一次，Athlon系统和Opteron系统的得分有了相当的差距，而且x86-64版本的Opteron系统性能提高了26％，使得它的表现远优于Pentium 4系统。



　　在这项测试中，Opteron系统比Athlon系统快了33％，虽然还是没法赶上Pentium 4系统。很明显Opteron处理器上的x87 浮点运算单元相对于Athlon处理器又向前迈进了一步。又一次地，x86-64 binary 实际上略微慢于x86-32 binary。不过这一次，loop-unrolling看起来起到了反面的作用，因为平均数组的大小要比在life benchmark测试中的大了许多。

　　最后，我们将会讨论64位的x86-64构架的性能（包括浮点运算性能）……
64位数据处理的性能测试

　　Opteron 拥有64位通用寄存器，所以任何使用64位整数运算的代码都会从中受益。使用32位的寄存器来做64位的整数乘法需要4次32位的乘法运算，而1次64位的加法运算则需要2次32位的加法运算。为了展示这点，我们在Opteron系统上进行一次定制的微型测试（micro-benchmark），也就是在两个数组的整数上进行了一次数量积（dot product）运算，这需要相当多的乘法运算，我们使用了32位和64位整数版本和用GCC编译的x86-64代码x86-32代码。

整数性数据尺寸 x86-32 速度 x86-64 速度 提高的百分比
32-bits 437 581 33%
64-bits 96.2 437 354%

　　X86-64版本在32位整数运算中要快33％，很大可能是由于更好的loop-unrolling（解循环）。在64位运算中，x86-64构架获得高出x86-32构架354％的结果（是x86-32构架的4.54倍），因为x86-64不但能从更多的寄存器，还能从64位处理（processing）中获益。请注意，x86-64构架在64位运算中的结果与x86-32构架在32位运算中的结果完全一致，当数据的复杂性和运算能力都成倍增加后，性能表现还是一样（与原来的相比）。

　　这项微型测试完全证实了这个显而易见的事实－ 使用64位代码来进行64位运算要比使用32位代码来进行64位运算快得多。不幸的是，我们还没有得到在相同情况采用了SSE-2指令集的测试结果，SSE-2 指令集也可以进行整数运算，并且从理论上说，他们还可以替代64位通用寄存器。

　　在现实生活中，却很少有benchmark 软件能够达到100％的缓存命中率，或者仅进行64位运算。用一种更为现实的方式来表示64位整肃运算的优势，我们找来了一些可以进行那样的运算的benchmark（带有C 源代码的）。金融应用程序（需要精确算法，而不是近似的浮点运算），以及加密算法都是很好的候选者。虽然我们也找到了许多整体上能够算上候选者的benchmark软件，不过只有一个倍证明可以与x86-64构架下能够编译，并且还是在经过对源代码进行了调整之后－不是所有的C代码都能在多个构架和编译器之间移植的。

　　这项benchmark就是John Tromp编写的Fhourstones 2.0 connect-4，这是一个采用64位整数来对hash数据结构进行运算:

　　这项非常出名的游戏是这么实施的：在一块垂直的板上，有6排，每排7个柱子，然后两个玩家轮流从一个柱子上丢下硬币（counters），第一个使得4个硬币排成一个水平、垂直或者对角线行的玩家获胜，如果在第42次行动后还没有人获得成功，游戏就算打平。――――个人认为这个可用可不用

　　这项测试使用了2个用GCC创建的binary（二进制库），两个都进行了相同的优化，不过其中一个使用了x86-64代码。



　　不幸的是，这项benchmark看起来从更大容量的缓存中受益更多，这使得很难通过结果来考察从CPU核心方面的表现 － 测试过程使用了最多5.4MB 内存。x86-64 binary 得到了26％ 的性能提升，所以很明显最后结果并没有受到Opteron系统的最大限制并不在主内存系统上。
使用Flops来测试浮点性能

　　我们以前也用过Flops来查看在CPU核心层次上的浮点性能表现。这项benchmark测试有9个模块，每个模块都有不同浮点运算集，我们得到6个不同系统的测试结果：采用了GCC的1.8GHz Athlon 系统（Intel的CC编译器得到的得分是相同的）、使用一个x86-32 GCC binary 的1.8GHz Opteron 系统、使用x86-64 GCC binary 的1.8GHz Opteron 系统、使用x86-64 GCC binary 的1.8GHz Opteron 系统、使用x86-32 binary （使用带有SSE-2 优化的Intel C编译器）的1.8GHz Opteron 系统、使用Intel C 编译器的2.8 GHz Pentium 4 (无超线程技术)以及使用Sun C 编译器的1.05GHz UltraSPARC III Cu系统。

模块 1.8GHz Athlon(x86-32 GCC) 1.8GHz Opteron(x86-32 SSE2 GCC) 1.8GHz Opteron(x86-64 GCC) 1.8GHz Opteron
(x86-32 SSE2 ICC) 2.8GHz Pentium 4(x86-32 SSE2 ICC) 1.05GHz UltraSPARC III Cu(SPARC v9.2 SCC)
1 759 863 1079 1068 1138  865
2 492 907 716 701 461 525
3 1189 1278 1508 1696 2058 1956
4 908 1167 1815 1769 2299 1901
5 1001 1205 1311 1489 2202 1668
6 1216 1355 1385 1872 2330 1846
7 325 326 397 388 324 247
8 1145 1117 1360 1786 2265 1801

　　Opteron系统轻易击败了同样时钟频率的Athlon系统，并且在使用了x86-64代码后优势就更加明显，不过即使这样，还是没有达到主频更高、经过SSE-2 优化的Pentium 4 系统的测试水平。不过最快的Athlon 64 处理器能够达到什么样的性能倒是让人期待，看起来2.4GHz 的Athlon 64 很可能会在性能上超过3.2 GHz 的Pentium 4处理器。而经过了相当的x86-64 优化的编译器能够带来多少的性能差异也还不明了。Pentium 4的高主频在这次测试中获得了胜利，但你会很吃惊地发现采用0.18um制程的1.05GHz UltraSPARC III Cu竟然与采用0.13um制程的 1.8GHz Opteron系统打成平手（4胜4负）。当采用0.13um制程的时候，UltraSPARC IIIi处理器将能够达到1.6GHz，而且目前的系统价格也与Opteron系统在类似的水平。因为UltraSPARC IIIi拥有与 UltraSPARC III Cu相同的核心，所以Flops 的测试结果会随着主频的提高而线形提升。潜在的用户们还需要等待那些高主频的处理器多长时间还不明确，Sun的 编译器套装的价格为995美元，不过因为浮点性能要比GCC binary 高出3－4倍，所以这个还是很需要的。

　　Opteron：目前为止我们得出的结论

　　Opteron是一款真正的SledgeHammer处理器吗？

　　我们认为Opteron处理器是一款真正的SledgeHammer处理器。3D Max性能高出20％，目前为止最快完成矩阵乘法，最高提升了38％的MySQL 性能，最高提升了40％的Java 应用程序性能（SPECjbb），Opteron性能为许多HPC，离线渲染（offline rendering）以及服务器市场的人士提供了相当不错的性能。如果只是为了自己的用途开发软件，用户也可以在使用x86-64编译器编译的时候取得较大的性能提升，正如我们前面所阐述的那样。如果使用的是64为整数数据，性能的提升就不仅仅是相当不错（significant），而会是相当巨大了（spectacular）。

　　当然，它也不是一个性价比的赢家，因为它比3.06GHz 的Pentium 4 Xeon更加昂贵，但在一些情况比 2.8 GHz Xeon还慢一些。在这个时间点，因为Opteron处理器还被限制在较低的时钟频率上，你就必须首先分析一下，你的应用程序是否真正适合Opteron处理器。不过真正不适合的应用程序是相当少的：Opteron处理器在微软 SQL Server 2000中的表现并不太令人信服，但也仅仅如此而已。

　　但这仅仅是个开始。NUMA、64位操作系统、更好的编译器以及64位驱动的使用，都将给整个Opteron系统性能带来很大的提升。而且很大可能AMD 在今年内处理器会超过1.8GHz 水平。一旦它的电路工程学获得了SOI 电路设计的诀窍，（也有报道说他们已经获得了），AMD将会在Opteron处理器上达到更高的时钟频率（和Athlon处理器相比）。略微长一些不过更加平衡的管线以及SOI工艺将会很好地解决这个问题，并且将Opteron 推向2.2 GHz ，甚至更高。

斜晖

CPU我选择AMD的

jinxingvenus

强顶，我强烈支持AMD，因为电脑的发展，特别是cpu的发展，它一直是功不可抹的。

gunguymadman007

问一下楼主    我发帖子的时候怎么图片和文字不能同时发啊

zsq800

我看的都有点晕了
太多了啊
下次请分几段来说啊!!

loveless

拒绝垄断！我从k6-2就支持你了，我的amd，忘不了我的k6-2主机，我现在用的athlon-1700+,你真卖力啊,把你超到场2600+,266FSB变333fsb,强啊，明年我决定了啊！athlon 64,我爱你！明年我带你回家！请大家来支持amd，不然没了amd ,P4 不知道要卖多少贵啊！！！！ 大家来支持啊！！！有没有人啊 ？？？

zsq800

非常感谢你给了我们关于AMD的过去和现在
！！
通过你的介绍，我对AMD有了更深的了解，我会一如即往的支持AMD！！

xmyjm

俺可也是一个AMD的fans了,从买的第一台机子K6-2开始,到现在的AthlonXP 2500+.

CQ_8086

  kao !这么变态，才发现AMD这么好！！！一顶要顶！！

我是学图形3D设计的，现在的机子是AMD2500+的CPU。啊 ！！！！！！看了你的数据才发现他那么好！真是爱死AMD了`永远支持他！

更感谢 楼主！第一次上，就看道这么好的东西` `顶``````