不懈的斗士（AMD处理器）

弱智

不错的文章。
AMD把Intel的技术开发老总挖了过来，
才真正开始推出能和Intel相对应的K7 CPU。

但是Slot A的图反了吧？

轩辕砍刀

呵呵，弱智兄眼力真不错，确实是Slot A的屁股

轩辕砍刀

ding

simbasun

hoho，太长了。。。看晕了。。

轩辕砍刀

长吗？比inter的短多了。我还打算在发一些内容那。

轩辕砍刀

AMD Opteron处理器的发布已经有了一段时间，它的发布在工作站和服务器芯片市场上引起不小的震动，这不仅因为它是AMD第一款真正能够在服务器市场上打败Xeon处理器的产品，还因为它是第一款64位x86处理器。作为64位处理器，它能够达到至少1024GB的内存编址空间以及256TB的虚拟内存编址空间。
考虑到大多数芯片组和图形芯片厂商都许诺要支持AMD的64位平台，要寻找64位的驱动应该不成问题。更进一步地说，在一个具有64位运算能力的操作系统上，每个现有的32位应用程序应该也能使用4GB的内存空间。

　　所以人们对于AMD极度灵活的Opteron芯片投以巨大的关注就不足为怪了。Opteron被设计为适用于高产量的1－8way 服务器市场，这块市场占了整个服务器市场的99％。还有一些系统设计厂商也准备把Opteron处理器推向更大的系统中。 对于像AMD这样的处理器厂商，焦点是要与占据了90％服务器处理器市场的Intel Xeon处理器争夺巨量销售额。



　　1U Newisys 2100服务器采用了双Opteron处理器设计，而另一个4路 3U服务器将会在下个月上市。4－way 服务器肯定不会是Opteron发展道路上的最后一桶金，因为Newisys计划在今年的第四季度发布32路的Opteron服务器。 2－way Opteron服务器的价格可以在下面的列表中找到。1－way 型号的产品和以及4－way和更大型号的产品的将会拥有不同的model号和价格。 处理器 时钟频率 每单位价格（1000块）
Opteron Model 240 1.4GHz 283美元
Opteron Model 242 1.6GHz 690美元
Opteron Model 244 1.8GHz 794美元
　　从AMD的报价可以看出他的雄心。1.6GHz Opteron处理器的价格比2.8GHz Xeon处理器还贵，而1.8GHz 型号的处理器比3.06GHz Xeon处理器还略贵一点。
　　随着工作站和服务器应用程序逐渐受到当前32位处理器的4GB内存限制，很明显我们需要一个比华而不实的PSE和PAE(处理器中控制寄存器CR4 的 bit 4和bit 5，在 Pentium 和以后的处理器才有)更好的解决方案。而更糟的就是4GB的虚拟内存限制。今天，我们都还不能在虚拟内存存储一个4GB的文件。因为系统核心（kernel）和用户进程要分享这微不足道的4GB虚拟内存，应用程序可能会被限制在3GB或者更少的内存中。一个庞大的256TB虚拟内存毫无疑问将会使得操纵海量数据更为容易。

　　Opteron的主要卖点就是它仍然能够以高速度运行纯32位x86应用程序，而Intel的Itanium处理器仅能运行专门为它进行编译的应用程序。作为一款经过巨大改进的带有64位扩展的Athlon处理器，这款AMD最新处理器能够在一个32位操作系统上和其他Athlon处理器一样运行32位x86应用程序。如果硬件厂商为用户的系统提供了64位的驱动程序，那么用户就可以安装一个64位的操作系统而在同样的操作系统上运行32位和64位应用程序。
对于一些只追求结果的读者，也许一切都不重要，他们最关心的问题是Opteron到底有多强劲，它在实际应用中表现如何，相对于它的竞争者而言，它处在什么位置，这就是本文力求寻找的答案。仅管Opteron发布以来已有一些它的测试结果公布，本文的测试更侧重于它在实际应用中的体现（特别是在服务器领域），因此会对一些服务器的设置有较详尽的描述。

　　Opteron的主要目标市场是HPC领域（高性能计算），服务器领域（Web服务器，数据库服务器，OLTP服务器）以及图象处理平台（rendering farm），为此，我们针对这些平台进行了测试了。我们不还进行了组件测试，如内存控制器，缓存控制器以及Sciencemark的浮点运算单元（FPU unit）和其他的综合的测试。如果你更为喜欢Linux，你将会很高兴地发现我们也在32位SuSE Linux 8企业版服务器，64位SuSE Linux 8 企业版服务器，采用了Pentium 4优化的Debian Linux（Kernel 2.4.20）和采用了k7-SMP优化的Debian Linux（Kernel 2.4.20）进行了测试。当然，我们也在Windows 2000 服务器上进行了不少测试。

　　我们将此文分为三个部分，在第一部分里，我们会再次回顾Opteron的一些产品架构特性并结合此次测试中一些对处理器组件的测试结果做出分析，这部分里，我们会对Opteron处为一款处理器的基本性能有个概括的印象。在第二部分里，我们将详细的了解Opteron处理器在测试中的的主要运行平台--Newisys 2100，从这里，我们可以窥见AMD如何在竞争激烈的服务器市场上登陆。当然，我们也会在这部分介绍其它一些进行对比测试的平台，第三部分，我们会对Opteron在各种具体应用环境下的表现进行测试，并对此次测试的结果进行了总结。那些只关注结果的朋友一定不要错过这里：）

　　了解Opeterod

　　在我们开始之前，让我们快速浏览Opteron之所以成为Opteron的各个方面：

　　SledgeHammer构架

　　由于对于Hammer处理器构架的深度探讨已经超越了本文的范围，让我们简单看一下什么使得Opteron能够比同频率的Athlon处理器取得更高的峰值性能。
　　· 集成了内存控制器，双通道DDR333内存
　　· 单独的HyperTransport总线来供处理器间通讯以及处理器与AGP通道和南桥通讯使用。
　　· 支持SSE－2指令集以及16个64位长模式寄存器
　　· 12级整数管线（Athlon：10），17级浮点管线（Athlon：15），频率更高，具体数据也会略高一些
　　· 一条额外的管线级来分析指令互独立性，在解码后马上进行
　　· 略深的整数缓存（3x8而不是原来的3x6）
　　· L1 指令缓存 TLB从24条增加到40条
　　· L1 缓存TLB增加了一倍（从256条增加到512条）
　　· Flush filter允许多进程共享TLB
　　· 更好的分支预测以及在全局历史计数器中的16K分支预测器（以前是4K）

　　有一点很重要，就是在今天Canterwood的理论上的6.4GB/秒的带宽，Opteron的5.4GB/秒的带宽可能不太醒目，但Opteron拥有一条单独的连接到AGP通道上的Hypertransport总线，或者具体的说，在我们的测试的系统里，连接到AMD8131芯片（这块芯片连接到PCI-X子系统）。这意味着将给系统带来更快的读写速度，因为数据传输将不再通过内存系统，而会直接CPU发送到AGP卡。Athlon 64和Opteron处理器都能够在普通内存带宽（Opteron系统是5.3GB/秒）的基础上再利用额外的带宽（3.2GB/秒双全工）。不过在这次测试中，我们的系统并没有AGP通道，所以这些额外的特性可能不会对性能提高带来太大帮助，因为PCI-X设备需要从内存中获得他们需要的数据（通过DMA传输）。这意味着额外的Hypertransport总线带来的带宽在这种情况下意义不大。不过，我们还是希望这个特性能在我们测试Opteron工作站的时候发挥作用，因为海量的几何图形需要在快速读写的基础上进行传输。
Opteron 构架 － 重装载（Reloaded）

　　正如你所看到的，后端设计并没有太大变化。



　　与后端完全相反，前端设计经过了显著优化。在指令被解码后，指令就会在类型和相互依赖性（dependencies）的基础上被分析。这就允许处理器来优化这一过程，那些指令应该被一起发送到3条管线（pipeline）中，这样也会使指令计划（scheduling）更加有效。

　　你可能会问，为什么AMD会将Opteron作为第八代处理器，而实际上它看起来只不过像是吃了兴奋剂的第七代Athlon处理器。不过中肯的提问方式应该是“什么使得Opteron更像一个最强现代处理器的竞争者，而不是一个虚张声势者”。

　　答案来自于两个关系到处理器性能的重要方面：内存延迟和条件分支（conditional branches）： 50％的常用应用程序中的x86 指令都是装载（Load）或者储存（Store）。Load发生的几率为Store的两倍左右，这并不太令人吃惊。大多数的算法和逻辑运算都装载2个数据变量，然后对两个变量进行对比/添加/乘法运算，然后将得到的结果存储回去。”

　　典型x86程序的14％－16％部分都是分支程序，并且这些分支程序的92％是有条件的（conditional）。换句话说，除了装载和存储外，“分支”可能就是x86程序中最重要的指令了。” 因为装载/存储和分支占了指令的很大部分，更多的单元和管线都起不了太大作用。虽然一个6条管线的构架听起来很吸引人，不过集成的内存控制器、更好的分支预测、效率更高的乱序计划和更大的TLB（Translation Look-aside Buffers ）才是提高IPC（每时钟循环的指令数）的更好方式。
Opteron：也是一款服务器处理器

　　一款服务器处理器需要的不仅仅是一个好的构架。许多服务器必须全天候工作，而且人们希望在一个机架里塞进尽可能多的服务器组件。更为重要的是，服务器中的所有数据必须十分可靠而且采用冗余的方式存储，因为没人希望因为出现机械故障就丢失几个星期的工作成果。

　　让我们来看看Linux CPUinfo 工具都报告了些什么。



　　有趣的是，Opteron依旧支持36位PSE――自从Pentium Pro开始就为所有Intel处理器所支持的36位物理编址扩展。这使得Opteron能像Xeon一样利用PAE。即使在今天的32位操作系统，Opteron也能支持最大64GB内存编址，虽然它的效能要比64位系统差很多。

　　Athlon系统的弱点之一就是它的脆弱的核心。如果用户在安装散热器过程中用力太大，核心的几个角就会破损。如果散热器没有与核心充分接触，那么核心发出的唯一信息就是缕缕青烟。虽然用户能够通过尽量小心来避免这些灾难，Athlon MP处理器感觉上还是没有Xeon或者Pentium 4处理器那么安全。这些处理器上的散热器能够防止温度急剧上升并为其他电路提供足够的时间来自动调节或者关闭处理器。

　　据来自AMD的消息，Opteron并没有具备自动调节特性（throttling），但却具有Thermtrip特性（温度过高时发送Thermtrip信号来关闭系统）。AMD没有给我们提供太多细节，但Thermtrip是一个快速的核心内的电路，通过这个电路能够强制执行一个防止过热机制，快到足够防止给处理器带来任何损坏。你能相信吗？--即使你在没有散热器地情况下启动一台Opteron系统（这套机制也能发挥作用）！ 数据保护 Opteron Athlon MP Xeon
L1-data Cache ECC 奇偶校验 ECC
L2-Cache ECC ECC ECC
内存控制器 ECC + Chipkill N/A ECC + Chipkill
Thermal 保护 Opteron Athlon MP Xeon
散热器 yes no yes
过热时关闭系统（反应时间） 核心内thermal二极管 (慢) 核心内thermal二极管(慢) 时钟 Throttling (快)
防止温度过高带来损害 Thermtrip (快) 无 时钟 Throttling (快)
　　这是多么巨大的一个飞跃呀。Opteron和Athlon一样，也拥有一个核心内的thermal二极管，（往正确的方向又迈出了一步）。不过这一次主板能够恰当地支持这一特性。进一步地说，L1 cache也有了ECC内存的保护，而不是Athlon的简单的奇偶校验（仅仅1比特的探测，而且没有更正能力）的保护。内存控制器同样受到ECC技术的保护，并且能够去处坏的内存块。

　　硬件过滤（Hardware scrubbing）功能在所有的受ECC保护的阵列上实施了，其中也包括DRAM。硬件过滤功能是从大型机上传过来的技术。它的主要功能是在空闲时间读取内存中的数据，寻找并更正其中的错误。不过，当x86服务器厂商谈论硬件过滤的时候，他们所指的是在处理器请求数据后，在数据抵达处理器的过程中的，通过ECC技术检查，探测以及更正单比特错误。

轩辕砍刀

一个好的总表要比千言万语更好，所以下面就是一张总表 特性 Opteron Xeon

Xeon MP Itanium II Athlon MP
时钟频率 1.4- 1.8 GHz 2 - 3.06 GHz 1.4 - 2 GHz 1 GHz 1.6 - 2.213 GHz
生产工艺 0.13 SOI Cu 0.13 Cu 0.13 Cu 0.18 0.13 Cu
晶体管数目(百万) 105.9 55?/td>; ? 221 37.5
电压 1.55V 1.5-1.55V 1.5V ? 1.65V
核心面积 (mm) 193 131?/td>; ? 464 80
多处理版本以及编址空间 Opteron  Xeon Xeon MP Itanium II Athlon MP
典型的多处理器系统 2- 8 way(最高 32way) 2way 2-8way (最高 32way) 2-8 way(最高 64way) 2way
最大物理编址空间 40位1024 GB flat 36位64 GB PSE 36位64 GB PSE 50位1024 TB 4 GB
最大虚拟空间 48位256 TB 4 GB 4 GB 60位1024000 TB 4 GB
处理器能耗 Opteron Xeon Xeon MP Itanium II Athlon MP
FPU单元（浮点运算器） 2 FMUL/FADD 1 FSTORE 1 FMUL/FADD 1 FSTORE 1 FMUL/FADD? 1 FSTORE 2 FMAC 2 FMUL/FADD 1 FSTORE
整数单元/装载/存储 3 Int / 3 AGU 2 DP* + 1 Slow /1 Load /1 Store 2 DP* + 1 Slow /1 Load /1 Store 6 Int / 2 Load / 2 Store 3 Int / 3 AGU
SIMD 1 x SSE2/3DNow!/SSE 1 x SSE2/SSE 1 x SSE2/SSE 1 x SSE 1 x 3DNow!/SSE
缓存配置 Opteron Xeon Xeon MP Itanium II Athlon MP
L1-cache (数据/缓存) 64/64 KB 8 KB/ +-20 KB** 8 KB/ +-20 KB** 16 KB/ 16KB 64/64 KB
L1-cache latency (装载时) 3 2 2 2 3
L2-cache 1 MB 512 KB 512 KB 256 KB 256 KB
L2-cache 带宽 128 bit (x) 256 bit 256 bit 256 bit 64 bit
L2-cache Latency (装载时，外加L1 cache latency) 16(*) 9-20 9-20 5 11-20 (*)
L3-cache - - 1 - 2 MB 3 MB -
内存 Opteron Xeon Xeon MP Itanium II Athlon MP
内存配置 2 x DDR333 2 x DDR266 2xDDR200/266 4xDDR266 DDR266
最大为处理器提供的内存带宽 5.4 GB/s 4.2 GB/s 3.2 GB/s 6.4 GB/s 2.1 GB/s

　　*Pentium 4构架的处理器（Xeon/Xeon MP）包含了2个双 ALU（算术逻辑处理单元） － ALU以双倍于核心的速度运行

　　**12000条微指令（Micro ops），大约相当于20KB x86指令缓存，AMD没有证实这条消息，这条消息是来自于sciencemark

　　ECC保护，大容量的L2 cache以及它的内存控制器以及采用的105.9M晶体管都使得Opteron成为一款体积较大的处理器。



　　1.55V的电压只是针对1.8GHz Opteron。我们的测试系统的BIOS建议Opteron处理器一般应使用的电压为1.45V。



　　规格已经介绍得够多了，让我们分析一些深度的测试结果。
     Opteron内存、带宽分析

　　Opteron系统的PR指标很不错，但最有说服力的还是真实的测试数据。我们采用了在Windows 2000 Server （打了SP3补丁）下运行Sciencemark2.0 Membench，来展示Opteron系统的全新缓存和内存子系统。



　　相同时钟频率下，Opteron系统的L2 cache比Athlon系统快了30％左右。这证明Opteron系统要么采用了128位 cache，要么采用了经过更好优化的64位接口。不过AMD不愿意证实究竟是那一个。不论那种情况下，Athlon构架中的又一个瓶颈已经被扩宽了。



　　注意，单Xeon系统仅比双Xeon系统快了4％，而单Opteron系统比双Opteron系统快了至少21％。一个很可能的原因是Windows 2000 Server并不支持 （cc）NUMA（非均匀内存存取结构）。有两种可能的内存存取：本地内存存取（这种方式速度快低延迟，带宽可达到5.3GB/秒）和远程内存存取（这种方式要慢一些，延迟更高，带宽为3.2GB/秒）。

　Windows Server 2003的确支持NUMA特性。这意味着这个版本的操作系统已经意识到远程访问要慢许多，而在需要数据之前就从远程内存子系统预读取数据可以优化内存的读取性能。仅仅通过BIOS升级并升级到Windows 2003就能使系统支持NUMA特性。AMD的Bill Robbins这样说:

　　“Newisys公司最新的Beta版bios能够在Windows Server 2003 beta的环境下充分利用NUMA特性。我们已经发现这款BIOS显著地改经了内存子系统地性能。并且随着Newisys不断开发新地BIOS，我们的确期望Newisys公司具备NUMA功能的BIOS为业界带来更多的利益。”

　　“NUMA是微软公司的一项新的内存管理特性，这项特性能使AMD 64位平台更加有效地管理系统内存资源。当系统具备多个内存控制器和使用了多个memory bank（内存组）的时候，性能的提升最为明显，正如我们所测试的采用Newisys和Opteron处理器的服务器一样。这项来自微软的特性是一项很了不起的成果，在目前，受益最多的还是AMD64平台。”

　　我们可以判断说，当我们在32位的Windows 2003上，而不是Windows 2000 server上进行测试，Opteron系统的性能还会提高一些。我们会在迟一些的时候进行这项测试，并随后公布。现在让我们来看看Opteron 内存子系统的延迟状况。
Opteron内存延迟分析

　　可能你已经注意到我们在总表里写下了Opteron拥有更低的最高L2 cache延迟（相对于Athlon）Sciencemark Membench的确证明了Hammer处理器的最大延迟为16个时钟循环（相对于Athlon MP提高了4个时钟循环）。

　　接下来，我们通过Sciencemark来研究集成的内存控制器所带来的影响。注意我们用的绝对时间来标识延迟。根据Newisys的建议，我们没有从双处理器的系统中去除第二块CPU来进行1－way测试，而是强迫系统优先使用第一颗处理器，这样产生的结果要比使用单处理器的系统要略差一点。我们在对Xeon进行测试的时候也是如此。



　　Opteron的延迟仅为Athlon的一半左右。无可否认，Athlon系统采用的是DDR266内存，而Opteron系统采用的DDR333。不过，我们之前进行的试验显示，采用DDR333相对于采用DDR266仅会降低延迟5－7％左右。

　　集成的内存控制器表现相当不错，不过，又一次地，Windows 2000 不能完全利用双处理器模式的优势。再加上性能优异的Intel E7501芯片组，就使得Opteron系统对于Xeon系统的延迟优势相当的小（大约10％）。

　　当然，当你从CPU的角度来看延迟的问题，又完全不同了。这个时候要考虑的仅仅是CPU需要等待多少个时钟循环来得到它需要的数据。


　　当内存读取使得CPU停滞的时候，Opteron系统浪费的时间要更少。

　　我们也采用了Stefan Manegold 写的Calibrator v0.9e来进行测试。







　　测试结果似乎证明了Opteron系统拥有更好的内存延迟（大约16％的优势）。整合的内存控制器发挥了作用，不过，这还不能带来根本性的变化。此外，我们在这次测试中还取得了另一个系统的测试结果―――550 MHz UltraSPARC IIe。UltraSPARC IIe是为单处理器系统而设计的，但是在这里来作为对比的对象也是很有趣的，因为和Opteron一样，它也集成了内存控制器。实际上，我们看到UltraSPARC IIe的L2 miss 延迟要比Opteron的更低（12％左右），虽然预计中单处理器系统与双处理器系统的延迟差距会更大一些。

　　看了以上部分，你可能已经对Opteron的一些新特性和基本性能有了概括的印象，在此文的下一部分，我们将介绍此次对比测试中使用的硬件平台。

轩辕砍刀

欢迎来到傲龙处理器应用测试第二部分，在这部分中我们将介绍测试中使用的Opteron服务器平台以及其它对比测试平台的配置。

　　下面先让我们来看看我们的测试单元，Newisys 2100 服务器……

　　Newisys：AMD进入服务器市场的登陆场

　　进入服务器市场需要的不仅是CPU，还需要厂商能够构建一个完整的平台。AMD在这点上很聪明，他们看到了仅靠他们自己的力量是做不到的。AMD的Hammer处理器的展示确实使得IBM和DELL的服务器部门的许多人兴奋不已。Newisys公司于2000年8月成立，他们的目标就是创造AMD的SledgeHammer处理器在当时必需的平台。

　　Newisys的目标并不是将可装在机架上的服务器直接卖给用户，而是将他们的参考设计卖给1线及2线OEM厂商，然后这些厂商又会以自己的品牌将这些产品投放市场。换句话说，Newisys设计主板、定制的芯片以及系统管理软件，然后将这些组合在一起来构成一个完整的Opteron平台。OEM厂商可以自由选择其中的某些组件，或者购买整套服务器设计，最后打上自己的商标。

　　许多服务器业界人士相信AMD 的Opteron能够为服务器市场带来一个大的变化，Newisys就很好地支持了他们地观点。当你看了Newisys公司地介绍其管理层的网页，你就会发现其中的许多人都在服务器技术上经验丰富，并且曾经在IBM和DELL的高层工作过。Newisys公司的管理人员冒了一次险，他们离开了那些安全而且高收入的位置转而重新开始构建一套完整的平台。

　　最大的问题就是1线OEM厂商是否会与他们签约。在目前，答案是不会，不过这个问题需要时间才能获得所需的答案。2线OEM厂商倒是热情高涨：Avnet Applied Computing、Appro、RackSaver和Microway都将销售基于Newisys方案的Opteron服务器，并且对此相当兴奋。Newisys 2100 服务器

　　经过了我们的测试的第一款Newisys产品叫做Khepri。Khepri是埃及的一个神，他推动太阳越过天空，还使得太阳每天从地面升起。从诗歌的意义上说，可以说Khepri服务器将会在服务器这篇天空中推动AMD这颗太阳。不过Khepri采用了一个甲虫作为标志，……Newisys的人的确挺有幽默感。



　　不开玩笑了，Khepri或者说Newisys 2100服务器是一款采用双Opteron的1U服务器，它支持以下特性：
　　· 最高16GB DDR 333 ECC内存（每个CPU4条插槽）
　　· 一条完整的 133MHz PCI－X 插槽
　　· 一条66MHz 64位 PCI－X插槽（长度为标准长度的一半）
　　· 两条Gigabit（技嘉） Broadcom 5703 局域网连接
　　· 两条内部的 ATA或者热插拔 U320 SCSI 驱动器
　　· 一个嵌入的服务处理器，来进行先进系统管理 （advanced system management）
　　· 两条连接到服务处理器的10/100M连接

　　它的系统管理功能可能是市场上现有1U服务器中最先进的。你只需要给予服务器处理器一个静态IP地址，或者一个动态的DHCP IP地址，你就能从网络中的任何web浏览器远程控制服务器。这个特性不需要安装任何软件，并且完全独立于操作系统。

　　服务处理器运行一个嵌入式Linux 操作系统，而且系统管理软件是采用标准的Linux工具编写的。这意味着任何取得了管理软件许可证的用户都可以轻松地自行添加他们自己的代码。现在大多数的机架式服务器都自带了管理软件，但是用户还是常常需要购买其他所有者的模块。并且这些管理软件中很少有能够作为SNMP agent（代理）运行并管理活动目录服务（active directory）和NIS。我们还没能够深度测试这些软件，因为我们还没有足够的时间。服务处理器当然也能处理操作系统重启，系统健康，风扇和核心温度监控，能源与BIOS设置与更新。

　　下面就是1U双Opteron服务器的示意图：




　　Newisys为每个处理器提供了4条DIMM插槽，这一点很重要。相当多的主板厂商都为第一颗处理器设计4条插槽，而为第二颗处理器设计2条插槽。虽然双Opteron系统在两颗处理器使用了相同容量的内存的时候性能最好（在采用了支持NUMA特性的操作系统的时候），Newisys的主板具有更多的灵活性。

　　接下来，就是1U 机架式Opteron服务器的一次可视化旅程……
它看起来像什么？



　　当我们去除了Ultra320 SCSI 线缆，你就可以清晰地看到每颗处理器都能读取两条DIMM插槽上的512 MB ECC PC2700 DDR SDRAM 内存（一颗处理器两条，一共四条）。



　　最后我们在服务器上发现了2条PCI－X插槽，一条运行在133MHz，另一条运行在66MHz。
在BIOS里面，还可以设置内存的速度以及CPU。





　　由于我们不想在稳定性上冒险，并且由于超频的服务器是很少见的，我们并没有进行任何超频测试。不过超频明显是可能的，关掉Max FID，然后在Hammer Freq（FID）中输入恰当的代码。虽然这张表的数字停留在10（1.8GHz），但是可以输入从11到31的数字。

　　接下来，快速浏览一下对比系统以及我们的测试系统的配置……

进行对比的系统

　　我们需要一个好的竞争者来进行对比，很幸运，Gigabyte公司的Nicole Chia提供一个相称的对手。

　　Gigabyte GA-8IPXDR-E正是我们需要的稳定的E7501主板。



　　这块主板支持最高12GB DDR266 ECC内存，并且附带了双Adaptec 7902W SCSI控制器，还有两条ATA－100通道。它还提供了四条PCI－X插槽，每条都能运行在133/100/66MHz上。对于我们的测试更为重要的是它的双1G bit Intel RC82546EB LAN chip，直接与PCI－X总线相连。这块主板还支持控制台重定向（Console Redirection），我们将在随后的几篇回顾中详细讨论这项以及其他一些服务器主板特性。

测试系统配置：硬件

　　我们将在后面讨论每个测试平台的软件设置，因为我们使用了不同的配置来进行HPC、webserver、database server测试。桌面机被设置为使用1024x768x32位色，刷新率为75Hz的Windows系统，至于Linux系统，我们一般都使用命令行界面。

　　服务器1：Intel Pentium 4 2.4 GHz, 2.8 GHz, 3.06 GHz（打开了超线程）
　　· 技嘉GA-8INXP（E7205/ Granite bay芯片组） － 双通道DDR266
　　· 1.5GB内存：2x512MB 以及2x256MB Corsair PC3200 XMS (DDR-SDRAM)，运行在266MHz CAS 2（2－2－2－6）
　　· NIC：1GB Intel RC82540EM - Intel E1000 driver

　　服务器2：双AMD Athlon MP 2200
　　· Tyan Tiger MPX
　　· 2GB内存：4x512MB Crucial PC2100R - 250033R (2.5-3-3-6)
　　· NIC：1 Gb Edimax EN-9230TX-32 bit PCI – 标准Debian/Suse 驱动

　　服务器3：双AMD Opteron 240 （1.8GHz）
　　· Newisys Khepri
　　· 2GB：4x512 MB Infineon PC2700R - 250033R (2.5-3-3-6)
　　· NIC：Broadcom 5703, bcm5700 driver

　　服务器4：双Xeon DP 2.8 GHz - 533 MHz FSB
　　· 技嘉GA-8IPXDR-E主板
　　· 2 GB 4x512 MB Crucial PC2100R - 250033R (2.5-3-3-6)
　　· NIC: 1 Gb Intel RC82540EM - Intel E1000 driver.

　　客户机配置1： 1台双Xeon 2.8 GHz - 533 MHz FSB
　　· 微星GNB MAX FISR (E7205)
　　· 2x256 MB Crucial PC2100R - 250033R (2-2-2-6)
　　· NIC: 1 Gb Intel RC82546EB - Intel E1000 driver.

　　客户机配置2：4台Duron 1300 PC
　　· ECS K7S5A
　　· 384 MB PC133 SDRAM.
　　· NIC: 100 Mbit RTL 8139, standard driver

　　共享组件
　　· 希捷 36 GB - 320 MB/s SCSI 硬盘
　　· 迈拓 80 GB DiamondMax 740X 硬盘(7200 rpm, ATA-100/133)

　　软件
　　· Intel 芯片组inf驱动 5.09.1012

　　以上我们介绍了测试中使用的服务器平台，在下一部分里，我们将进入这篇文章的枋心部分，那就是Opteron在它的主战场——服务器市场上的各种典型应用中的测试表现。敬请关注。

轩辕砍刀

在上一篇文章中，我们集中介绍了测试所用的硬件平台，现在我们正式进入此文的枋心部分，了解一下Opteron系统在各种测试环境下的表现。

　　采用Opteron处理器的Webserver

　　我们的第一项任务就是现实的WEB服务器运行环境测试。Webserver在两种环境下进行测试：一种是4－5个客户机（的一种客户机：Duron 1300 PC）连接到我们的千兆交换机上的8个100M端口中的1个。这意味着我们将给服务器（连接到gigabit上行线路）带来40到50MB/秒的客户机网络流量。



4台客户机连接到Longshine千兆级上行交换机（ gigabit uplink switch）

　　我们第二套客户机配置为1台P4 2.8GHz PC，通过一个UTP5线缆连接到服务器上集成的千兆级Intel RC82540EM。在这种环境下，理论上可以达到100MB/秒的客户机与服务器间的网络流量。通过这种方式，我们就可以知道更多的客户机或者更高的网络带宽是否会给服务器带来更高的性能。

　　采用2.8GHz Pentium 4的客户机使用的Debian Linux kernel version 2.4.20-686-smp（这是对Pentium 4 超线程技术进行了优化的版本，虽然名字还是686）。采用Duron处理器配置的客户机使用的Debian Linux kernel version 2.4.20-k7-smp（这是稳定的2.4 Linux kernel的针对Athlon 处理器进行了优化的版本）。

　　对于性能测试，我们采用了httperf与autobench（一种由Julian T.J.Midgley用Perl语言编写的软件）一起使用的方案。具体过程就是针对一台服务器运行多次httperf，每次都会增加每秒的请求数。这套程序的测试结果使我们能够确切地观察到当工作负荷逐渐增加的时候，系统性能的表现情况，直到达到系统的性能峰值。

Autobench 和 httperf正在运行中

　　每次测试中，每个连接发布5次请求。测试被设置为对耗时超过5秒的请求都产生一个超时（timeout）错误，在处理"压缩消息板索引"（compressed message board index）的情况下超时（timeout）为10秒。

　　不过我们还是得自己重编译httperf，因为它仅能在拥有1024个文件描述符的客户机上运行（这是个老的Unix系统的每用户限制）。我们自己编译的httperf就没有这些限制。

　　因此客户机按如下设置

　　ulimit -n 10000, set number of open files to 10000 (default 1024)

　　双Athlon服务器使用的是Debian Linux kernel version 2.4.20-k7-smp，双Xeon使用的是Debian Linux kernel version 2.4.20-686-smp，Opteron使用的是SUSE SLES 8 kernel 2.4.19。因为这些核心是在针对各个服务器处理器进行了优化的核心中最稳定的。我们相信这样的测试还是很公平的。如果你像我们这样设置参数，相同核心的不同版本的性能表现应该都差不多。


Opteron系统上的32位SUSE操作系统通过PSE能够支持64GB内存

　　服务器设置了如下的参数：
　　· ulimit -n 64000, set number of open files to 64000 (default 1024)
　　· shmmax = 512288000 or 512 MB, shared memory maximum (default 33 MB)
　　· net.core.optmem_max=100000, maximum amount of option memory buffers, default 10240
　　· net.core.rmem_default=131071, default receive socket buffer size, default 65535
　　· net.core.rmem_max=131071, maximum receive socket buffer size, default 131071
　　· net.core.wmem_default=1000000, default send socket buffer size, default 65535
　　· net.core.wmem_max=1000000, maximum send socket buffer size, default 131071

　　当把我们的测试方法和其他的配置对比，你会发现下列3项参数在其他地方是被关掉了的。
　　· net.ipv4.tcp_timestamps=1, turns TCP timestamp support on, (default)
　　· net.ipv4.tcp_sack=0, turn SACK support on, (default)
　　· net.ipv4.tcp_window_scaling=0, turn TCP window scaling support off, (default on)

　　我们决定打开这些特性来使webserver能够在一个高延迟的广域网上表现出更好的性能。的确，我们进行测试的局域网延迟是很低的，不过大部分的webserver都是部署在互联网上。互联网可以说是一个延迟最高的广域网，或者将webserver比作在一个非常大的局域网上的内部网（Intranet）服务器。
接下来是我们的消息板索引性能测试（message board index benchmarks）

　　性能测试软件包括：
　　· Caucho Technology's Resin 2.1.6
　　· Java Virtual Machine 1.4.1_02 SDK
　　· Sybase ASE 11.9.2 for Linux

　　这些测试软件测试的是一个现实网站的产品应用程序，并使用了相同的数据集。全套的平台正如下面的图表所示：




　　简单地讲，客户机运行httperf，然后产生许多"HTTP GET"请求。看看上面这幅图，"internet"就是我们的交叉线缆（crossover cable），或者说千兆级交换机（gigabit switch）。Resin或其他的webserver（绿色部分）接受请求然后将回复发回到客户端。Java应用程序（黄色部分）从对象缓存中提取数据并产生HTTP服务器需要发回客户端的回复内容。缓存由数据库中的数据组成（蓝色）。
　　利用了缓存的Java Webserver Benchmark: 消息板索引
　　操作系统: Linux 2.4.20 / 2.4.19
　　多线程: 打开
　　内存:  800 - 850 MB
　　不同测试间的误差  3-4%
　　最大网络流量: 最高 15 MB/秒
　　我们的第一项测试是CPU运算密集型的，因为需要对我们的消息板编写索引。由于内容没有压缩，还需要相当的网络流量的支持。



　　Opteron系统在这项测试中所向披靡。对Opteron系统来说，运行Java应用程序和构造多线程的消息索引就像是它最擅长的任务。Opteron系统比占据第二位的双Xeon系统快了38％。双 3GHz Xeon系统可能会比双2.8GHz Xeon系统快7％左右（时钟频率提高，性能也随之提高），但还是无法触及Opteron系统性能上的优势。

　　因为消息索引可能大到几百KB，并且是从数以千计的Java对象中创建的，这项测试在缓存和内存方面的负荷是相当大的。但是当我们考虑Opteron这方面的优势（每颗CPU拥有128位内存接口以及1MB L2 cache），Opteron系统所体现的性能就不足为奇了。

　　超线程技术当然也有所帮助，因为这项测试是高度多线程的，不过产生消息索引才是最为严重的瓶颈。
使用了缓存和压缩的Java Webserver Benchmark：消息板索引
　　操作系统: Linux 2.4.20 / 2.4.19
　　多线程:   打开
　　内存:     850- 900 MB
　　不同测试间的误差:  2-3%
　　最大网络流量: 最大 1 MB/秒

　　快速的java性能很不错，不过一个网站管理员最关心的问题之一还是带宽。有时候更高的带宽所需的花费是巨大的，所以使用更高的带宽可能就是个代价昂贵的提议。那么，为什么不在服务器上用gzip压缩内容，然后再发送给客户端？几乎每个现有的浏览器都支持经过gzip处理的内容。



　　在这项测试中，我们在将网页发送到客户端之前先进行压缩。进行压缩所带来的额外计算需要使得性能降低了一半，不过这也使得网络I/O下降到了原先的1/15。虽然性能降低了（服务器端），不过这样节约下来的的带宽10倍地弥补了损失的性能。并且我们可以常常通过在带宽花费上节省下来的钱购买更快的硬件设备来弥补性能上的差异（服务器端）。

　　先前的不带压缩的性能测试结果是由数据的大小决定的，而带压缩的测试结果就将性能重点转移到了运算上。这样的结果就是2.8 GHz P4 Xeon系统得以缩小与Opteron系统的巨大差距。

　　有趣地是，当使用了超线程特性的时候，系统性能反而下降了。使用了超线程P4系统和Xeon系统的性能都更差了。一个可能的合理解释就是，gzip占掉了相当一部分L2 cache，并占用了Java 线程的一部分缓存空间。压缩还使更多单元处于繁忙状态，这样就会减弱超线程技术在充分利用空闲线程中的作用。

　　接下来，我们将会总结一下我们的Java/Resin benchmark结果，然后来看看SPECjbb2000。

　　使用了缓存和压缩的Java Webserver Benchmark：双 Mac 篇

　　操作系统: Linux 2.4.20 / 2.4.19
　　多线程:  打开
　　内存使用量:  750 - 800 MB
　　不同测试间的误差:  5-7%
　　最大网络流量: 最高 2.5 MB/s
　　在接下来的测试中，我们并不需要产生索引/树结构，我们仅仅请求一篇18KB的文章。



　　现在我们去除了创建消息板索引的负担，能够进行处理的线程数急剧上升。这意味着主要的性能焦点转移到了1颗CPU能够多快地处理器一定数量地java 线程。使用了超线程技术的双P4 Xeon系统能够一次处理4条线程，在性能上超过所有其他系统。双Opteron在性能上位于第二位，但还是领先于没有使用超线程技术的双Xeon系统。
Opteron系统在SPECjbb2000 测试中的性能表现


　　操作系统: Linux 2.4.20 / 2.4.19
　　多线程:  打开
　　内存使用量:  1000 - 1150 MB
　　不同测试间的误差:  1-3%
　　最大网络流量: N/A，直接作用在服务器上

　　SPECjbb2000是由标准性能评估公司（Standard Performance Evaluation Corporation ，SPEC）开发的一套性能测试软件，它会模拟一个事务处理服务器。让SPEC来告诉你更多吧：

　　"SPEcjbb2000是作为一套强调中间层的3层系统的Java程序来实施的。所有的3层都是在同一个JVM（java虚拟机）上实施的。这些层模拟一个典型的商业应用程序，第一层的用户生成输入，并造成中间层执行一些业务逻辑，中间层又会调用第三层的数据库。在SPECjbb2000中，用户层会随意输入一些内容，但它会完全执行中间层的业务逻辑，而第三层则由二进制树结构来代表，而不是一个单独的数据库。

　　SPECjbb2000 是完全自我装载和自我驱动的（生成它自己的数据，生成它自己的多线程操作，并且不需要JRE以外的任何软件包）。

　　SPECjbb2000是从TPC－C中得到灵感的，并且在它的模式、输入的产生以及操作资料库中都大致遵循了TPC－C的规范。SPECjbb2000用Java class替代了数据库表，用Java 对象替代了数据记录。这些对象通过B-Trees（也是一种Java对象）和其他的数据对象保留在内存中。所以SPECjbb2000并不进行磁盘读写操作。因为没有采用数据库，它并不支持实施关系型数据库时的带有ACID属性的对象。SPECjbb2000仅使用Java同步机制来同步对于共享对象的多线程访问。又因为用户并不存在于外部客户系统中，所以SPECjbb2000也不需要任何网络IO操作。

　　虽然SPECjbb2000是由TPC-C而引发出来的，但与TPC-C是完全不可相比的。SPECjbb2000完全寄存于内存中，使用了完全不同的数据集尺寸，带来了不同的工作负荷，不需要进行磁盘I/O，并且没有思考时间（think time）。它拥有一套不同的运行和报告规则，一套不同的测量吞吐量的方法以及一套不同的度量衡。

　　在SPECjbb2000中，每个仓库只有一个活动的终端（或者客户）。一个仓库就是一个存储数据的单元。它大概包含了25M存放在B-tree中的数据。终端直接映射到Java线程。每条线程都按次序执行操作，而每个操作都是从操作库中按概率分配的。因为在整个测试期间，仓库的数目是不断上升的，所以线程的数目也不断上升。"

　　SPECjbb2000至少使用198－300MB的空间，所以我们通过设置-Xms/-Xmx JVM给了它1024MB的空间。我们还确保了JVM确实是服务器版JVM，而不是客户机版JVM（这两者都包含在1.4.1_02 HotSpot Java SDK中）。


SPEC是标准性能评估公司的注册商标(spec.org)

　　Opteron系统拥有相对其他竞争者41％的优势，并证明了它是一个非常优秀的事务处理CPU。

　　现在我们将转到关系型数据库管理系统（RDBMS）性能（SQL Server 2000）……

轩辕砍刀

关系型数据库管理系统（RDBMS） 性能
到现在为止，我们为了取得更好的web性能，已经尽了最大可能降低对数据库的访问。不过，我们可以想象许多人都想知道Opteron系统和Xeon系统如何处理关系型数据库服务器，如微软的SQL Server和源代码公开数据库MySQL。

　　微软SQL Server 2000 SP3

　　操作系统: Windows 2000 Server SP3
　　多线程:  打开
　　内存使用量:  最大 980 MB
　　不同测试间的误差:  1-2%
　　最大网络流量: N/A，直接作用于服务器上

　　对于我们的微软 SQL Server测试，我们导入了5GB关于中型企业的数据。数据库由以下表组成：包含了460，000条单独记录的person表，这张表与document表是一对多关系。这对于不少于800，000条记录的表来说是很好的。此外，还有一张主要由序列号组成的表，大约有100，000条记录。最后，还有一张value表，它包含了一些其他表通过外键来引用的数据。一个简单例子就是，一张表有这样的字符串："Male（男性）"和"Female（女性）"。这张表中的记录被其他表中（例如person 表）的主键来引用。为了运行一个针对这张表的查询，我们将我们需要的字段通过主键连接在一起，并且在条件从句（where从句）中指定许多限制条件。然后数据库就会产生一张临时表（包含了按特定顺序排列的特定数据），然后将结果发送给我们。



　　在第一次测试中，我们查询了在特定时间段中名字字段以V开头的记录。我们不能展示实际的SQL查询，因为我们许诺不会泄漏这个大型数据库的实际内容。这条查询语句有3个JOIN连接，1个部分字符串搜索，以及一个日期限制（constraint）。

　　一条SELECT语句被执行了4次，我们抛弃了第一次的结果，因为它受到硬盘读写速度的影响。接下来的三次测试结果都是非常接近的，最后结果是这三次测试结果的平均值。每次我们运行的时候，都执行了一个"dbcc freeproccache"命令来确保得到的结果不是直接从操作系统内存中得来的。当数据库存在于操作系统的内存中（几乎没有磁盘读写），得到的记录集就必须被重新生成。每一个CPU的利用率都达到了60－90％（大多数时间在80－85％）。这条查询返回了8800条记录。

　　这是第一次我们遇到双Xeon系统在性能上以较大优势超过了Opteron系统。因为这项测试需要大约1GB内存，很可能Opteron从Windows 2000对于内存管理的不太高效中遭受了一些性能损失。同时这也是使用了超线程技术的Xeon系统的一次大胜利。

　　我们的下一个测试由一个类似的查询组成，不过结果按照一条ORDER BY语句进行排序，并且WHERE从句中的限制更少。



　　在这项测试中，Xeon系统与Opteron系统之间的差距被缩小了，但Xeon系统还是当之无愧的胜利者。接下来我们仅对4000条记录进行查询，不过采用了一些更为复杂的添加了OR……的条件语句。



　　添加了OR逻辑实际上使得Opteron系统相当高兴，现在Opteron系统的性能比使用了超线程的双Xeon系统更好。

　　SQL Server是一个流行的关系型数据库，特别是在Windows平台上。但是在Linux和其他的源代码公开的平台上呢？接下来让我们看看MySQL
MySQL 3.23.49－源代码公开数据库性能

　　多线程:   关闭
　　操作系统: Linux 2.4.20 / 2.4.19
　　内存使用量:  240 MB
　　不同测试间的误差:  3-5%
　　最高网络流量: N/A，直接作用于服务器上

　　对于这一系列的测试，我们从webserver中导入了400MB的HTTP日志到MySQL数据库中。在这项测试中，我们进行了复杂的数据挖掘（datamining）查询，然后记录这些系统所需的时间。并且由于这是我们自己的数据库，我们可以展示实际的查询语句。

　　SELECT COUNT(*) AS hits,SUM(data_size),f.type FROM files_map f,log l WHERE f.id=file_id GROUP BY f.type ORDER BY hits DESC



　　MySQL看起来很喜欢Athlon系统的构架，Opteron系统最多领先了23％，不过即使是Athlon2200＋也把P4系统丢在了后面。

　　SELECT COUNT(*) AS hits,-data_size FROM log WHERE data_size < 0 GROUP BY data_size ORDER BY hits DESC



　　又一次，AMD取得了一边倒的胜利。

　　SELECT COUNT(*) AS hits,FLOOR((data_size)/1024) AS kb FROM log WHERE data_size >;= 0 GROUP BY kb ORDER BY kb ASC



　　至少快了38％，Opteron系统一举取得了这项测试的胜利。
SELECT COUNT(*) AS hits,f.file FROM files_map f,log l WHERE f.type='' AND f.file LIKE '%/' AND f.id=l.file_id GROUP BY f.file ORDER BY hits DESC



　　SELECT COUNT(*) AS hits,f.file FROM files_map f,log l WHERE f.id=l.file_id GROUP BY f.file ORDER BY hits DESC LIMIT 50


两次较小优势的胜利，Opteron系统要快出6％。

　　HPC性能又如何呢？接下来：ScienceMark 2.0 和 Plasma Fusion……

　　HPC: ScienceMark 2.0

　　除了数据挖掘和事务处理，Opteron系统还瞄准了科研用途的HPTC市场。我们运行了"BLAS"benchmark软件，它类似于ScienceMark2.0其中一个组件，Linpack，进行矩阵乘法（matrix multiplication）浮点运算测试。不过与我们的C Linpack binary不同，BLAS进行了最大优化来保证完全利用CPU的缓存。所以BLAS使我们能了解大型矩阵乘法在特定CPU上的运算速度的真实情况。

　　更为有趣的是，BLAS能够测量SSE-2和X87性能，以及高等级语言（无ASM）的编译处理性能。不过它还是一个单线程的性能测试软件，所以即使在双处理器系统上运行，也只有一个处理器能够被利用。



　　Opteron处理器是首款支持SSE-2的AMD 处理器，下面就让我们来看看支持SSE-2 的AMD处理器的性能。当测试软件是针对矢量的时候，1.8GHz Opteron系统看起来达到了P4 Xeon at 2.8 GHz系统的性能水平。当测试软件是针对标量的时候，1.8GHz Opteron系统就极大地超过了它地竞争对手。



　　一个低延迟的内存子系统加上良好的cache性能，就完全释放了三条管线FPU（浮点运算单元）的能量。这些曾经隐藏在Athlon处理器中的能量，终于在Opteron处理器中释放了出来。



　　得到的结果与经过编译的测试软件一样，两次测试的唯一区别就是，x87汇编技术可能已经逐渐被淘汰。
Primordia 测试

　　下面摘自Sciencemark.org：

　　"这段代码计算量子力学中任何周期表中元素的每个电子的Hartree-Fock轨道。至于如何计算这个轨道就需要大量的篇幅才能说得清楚。总之，执行了一个有条理的循环。在循环的每一个阶段，每条轨道的哈特里（hartree 能量单位）、交换以及相关性可能都被计算出来。用户可以在广泛的算法中选择一个来计算这些潜在性。"


　　Primordia测试中最有意思的就数Opteron系统看起来随着CPU数目增加，性能提升最大。第二颗Opteron处理器带来了多出原先25％的性能，而第二颗Athlon处理器仅带来了多出原先14％的性能。

　　Plasma Fusion测试

　　Plasma 性能测试使我们使用的最新的测试软件之一。西蒙 布兰德博士给了我们一些关于这个软件的新信息：

　　"MHD代码的运算速度受到矩阵倒置的限制。这个矩阵是由210万行和210万列组成的，所有的数值都是双精度型的。不过这些数值却是分布得很稀疏……，一共有29个非零的对角线（diagonal）。当前的矩阵解决方法是一个重复的解决方法（双向变化的坡度解决方案）。这个解决方案使用了100次的重复来解决矩阵，每次重复由大约5个矩阵乘法器组成。正如前面所提到的，我们正积极寻找更好的单独和并行的解决方案。"（个人意见这段文字，可要可不要，因为涉及具体内容太多，不好翻译）

　　请注意这是一个单线程的benchmark软件。



　　Plasma在计算巨型但是分布稀疏的矩阵的时候，最需要1M L2 cache所带来的动力。不管如何，Opteron系统还是比他的兄弟快了一倍左右。并且因为集成了内存控制器，Opteron系统唤醒了深藏在Athlon/Opteron中的FPU（浮点运算单元）能量，并最终带来了极佳的性能。

　　我们已经谈过了这些系统在HPC和服务器上的性能表现，他们的3D表现又如何呢？
用Opteron系统进行图形渲染
很少有应用程序像现实效果处理（photo-realistic rendering）这么对3D性能有如此的要求。AMD相信内容创建行业将是Opteron系统的一个主要市场目标，那么就让我们来看看它是如何对付这些3D性能要求很高的应用程序的。

　　Kribi

　　将OpenGL卡生产商赶出市场是Kribi renderer的梦想。也许我们太夸张了，不过不管如何，Kribi，这个由Adept Development开发的产品，是一个相当优秀的3D软件渲染引擎。它最高能处理100亿个多边形！！这全因为它去除了隐藏的表面以及使用了实时现实效果渲染。

　　Kribi引擎使用了100％的软件渲染（一个纯CPU benchmark）并且不能在没有SSE指令集的情况下工作。所以它是一种SSE加FPU的benchmark软件。这次我们使用了Kribi 1.1，这是一个速度更快并且特别针对超线程技术进行了优化的版本。我测试了不同的型号，来确定那一种对性能有最大的影响。第一个场景－ City Ultra 是最为壮观的，不少于167亿个多边形。所有的结果都是按FPS（每秒帧数）来计算的。



　　Opteron系统与没有打开超线程的双Xeon系统的表现相接近，但由于对超线程技术进行了很好的优化，在打开超线程之后，Xeon系统成为表现最出色的软件渲染器。城市场景包含了1亿零7百万多边形。



　　接下来的Kribi benchmark 测试证实了我们开始的预测。