|
原生四核心
AMD已经让全世界都知道了他们的Barcelona是一个真的原生四核心，而Intel的四核心CPU不过是一个连体婴儿而已。原生四核心的设计可以Cache中的数据交换来得更为迅速。为了量化一个CPU从另一个CPU的Cache中获得最新数据的延迟时间，我们使用了Cache2Cache软件测出了以下数据。Cache2Cache是用来测算一个处理器读出到另一个处理器存储的传播时间，这里公布出来的数据大约为传播时间的两倍。
| Cache coherency ping-pong (ns) |
| |
Same die, same package |
Different die, same package |
Different die, different socket |
| Opteron 2350 |
152 |
N/A |
199 |
| Xeon E5345 |
59 |
154 |
225 |
| Xeon DP 5160 |
53 |
- |
237 |
| Xeon DP 5060 |
201 |
N/A |
265 |
| Xeon 7130 |
111 |
N/A |
348 |
| Opteron 880 |
134 |
N/A |
169-188 |
AMD的原生四核心和L1 Cache交换信息需要花费76ns的时间。不算是很长，但是和采用共享L2 Cache方式允许单个的双核心之间通过L2 Cache交换数据仅仅花费26ns-30ns的Xeon比较起来就不是很理想了。当你从Core0到Core3只见交换数据的时候，Intel的“连体婴儿”之间的通讯时间也仅仅比AMD的原生四核心之间的通讯慢了1ns。复杂的L1-L2-L3层次可能会抹杀了“原生”四核心的优势，我们还需要更多地了解这些复杂的层次。
以上是anandtech关于Cache测试数据的分析。我发表一下自己的观点，首先看一下三组数据，再同一个CPU同一个核心的情况下，Opteron 2350 Xeon E5345以及Xeon 7130的测试数据分别是152ns 53ns 111ns。可以明显的发现Core的构架取得了绝对的优势，就像原文作者所分析的共享L2 Cache是一个决定性的因素。从这些数据可以得出构架的强弱Core > K10 > NetBurst。但是在同一个CPU不同核心的测试E5345的成绩与2350很相似，也就是说，AMD通过共享L3的方式与Intel的FSB性能相当。进一步说明了在核心的设计方面Core确实是优秀的，至少在Cache方面是这样的。最后一组数据，不同CPU不同核心之间的数据交换AMD又取得了明显的胜利，这就说明AMD基于HT的直连构架相对于FSB来说是有相当的优势的。
内存子系统
AMD的新Opteron在内存子系统上的改进应该算是最为彻底的了，大概也就是L1没有发生变化，依然采用两路的关联64KB Cache，每三个周期完成一次存取。就像所有的CPU一样，新的Opteron 2350可以在一个周期内传输16byte的数据。
|
Read (MB/s) |
Write (MB/s) |
Copy (MB/s) |
Bytes/cycle (Read) |
Latency (ns) |
| Opteron 2350 2 GHz |
32117 |
16082 |
23935 |
16.06 |
1.5 |
| Xeon 5160 3.0 |
47860 |
47746 |
95475 |
15.95 |
1 |
| Xeon E5345 2.33 |
37226 |
37134 |
74268 |
15.96 |
1.3 |
| Opteron 2224 SE |
51127 |
25601 |
44080 |
15.98 |
0.9 |
| Opteron 8218HE 2.6 GHz |
41541 |
20801 |
35815 |
15.98 |
1.1 |
L2带宽问题已经困扰了AMD的构架很长时间了，回到K7雷鸟的时代，AMD简单得把L2 Cache固定在核心上，结果就是通过相对狭窄的64bit通道在L2和L1只见传送数据最快也只能每个周期2-3个byte的样子。K8的构架在这方面作了一些改进，性能大概提高了50%或者更多。但是即便是这样还是无法达到甚至都无法靠近Intel在L2方面的性能。在Barcelona的构架下，通往L1的数据通道被加倍到了256bit了，结果也在下表中显示出来了。
| Lavalys Everest L2 Bandwidth |
| |
Read (MB/s) |
Write (MB/s) |
Copy (MB/s) |
Bytes/cycle (Read) |
Bytes/cycle (write) |
Bytes/cycle (Copy) |
Latency (ns) |
| Opteron 2350 2 GHz |
14925 |
12170 |
13832 |
7.46 |
6.09 |
6.92 |
1.7 |
| Dual Xeon 5160 3.0 |
22019 |
17751 |
23628 |
7.34 |
5.92 |
7.88 |
5.7 |
| Xeon E5345 2.33 |
17610 |
14878 |
18291 |
7.55 |
6.38 |
7.84 |
6.4 |
| Opteron 2224 SE |
14636 |
12636 |
14630 |
4.57 |
3.95 |
4.57 |
3.8 |
| Opteron 8218HE 2.6 GHz |
11891 |
10266 |
11891 |
4.57 |
3.95 |
4.57 |
4.6 |
| Lavalys Everest L2 Comparisons |
| |
Bytes/cycle (Read) |
Bytes/cycle (write) |
Bytes/cycle (Copy) |
| Barcelona versus Santa Rosa |
63% |
54% |
51% |
| Barcelona versus Core |
-1% |
-5% |
-12% |
| Santa Rosa versus Core |
-39% |
-38% |
-42% |
Barcelona也就是Opteron 23xx相对于K8的带宽提升都超过了50%有的甚至达到了60%，我们还测试了15个周期内的延迟，这项测试中让AMD的L2 Cache和Intel的Core处在了同一个档次上。
第三代Opteron在内存控制器方面也作了相当大的改进
更深的缓冲：整合低延时的内存控制器已经成为Opteron的一个有力的武器。但是它能够从DDR2内存中能够榨取的带宽非常有限。只有当Opteron在高频率的时候这项技术才能从DDR2-667上获得比较多的性能优势。采用了更深层次应答缓冲的第三代Opteron在这方面有所改善，因为新的Barcelona采用了新的 Memory Optimizer 技术以及后面要提到的动态双电源管理技术。
写缓冲：当Socket939接口来带了双通道内存之后，我们发现总线的转换周期（turnaround cycle）对于Athlon64的性能影响是非常明显的。事实上，半双工的内存总线需要花费一些时间来在读和写操作之间作切换。当你在939的平台上八四个内存插槽都插满的时候，总线的周转周期将会从原来的一个周期自动变成两个周期。这可能会导致大约9%的性能下降，具体还需要看你所使用的应用程序对于内存的依赖程度。所以最佳的方式是你是你仅仅是用两个内存条组成双通道来保持总线转换周期在一个周期之内，当然能够让总线转换周期小到忽略不计是最好了。内存控制其中的一个16通道的写缓冲可以让Barcelona把写操作进行组包，然后按顺序的送出。（具体请参看本站的深入巴塞罗那一文）
更加灵活：内阁控制器都支持独立的64bit存取。
DRAM预取单元：DRAM预取单元用来当通常情况下应该从内存中存取数据的时候在内存需要数据之前从其中请求数据。
更好的“open page”管理：事先在内存中将正确的行确定下来，内存管理器只要再次选择正确的列就可以获得她想要的数据。而不是像之前先选择好正确的行，将其记录下来，在选择正确的列后才能确定正确的数据。这样可以节省不少的延迟时间还可以节省能耗。
分离的能源管理：给内存控制器和核心提供不同的电压，可以让内存控制器的频率高于核心，从而获得更高的性能。
下面就是用Lavalys Everest 4.0.11测试的内存带宽：
| Lavalys Everest Memory BW |
| |
Read (MB/s) |
Write (MB/s) |
Copy (MB/s) |
Bytes/cycle (Read) |
Bytes/cycle (write) |
Bytes/cycle (Copy) |
Latency (ns) |
| Opteron 2350 2 GHz |
5895 |
4463 |
6614 |
2.95 |
2.23 |
3.31 |
76 |
| Dual Xeon 5160 3.0 |
3656 |
2771 |
3800 |
1.22 |
0.92 |
1.27 |
112.2 |
| Xeon E5345 2.33 |
3578 |
2793 |
3665 |
1.53 |
1.2 |
1.57 |
114.9 |
| Opteron 2224 SE |
7466 |
6980 |
6863 |
2.33 |
2.18 |
2.14 |
58.9 |
| Opteron 8218HE 2.6 GHz |
6944 |
6186 |
5895 |
2.67 |
2.38 |
2.27 |
64 |
| Lavalys Everest Memory BW Comparison |
| |
Bytes/cycle (Read) |
Bytes/cycle (write) |
Bytes/cycle (Copy) |
Latency (ns) |
| Barcelona versus Santa Rosa |
26% |
2% |
54% |
29% |
| Barcelona versus Core |
92% |
86% |
111% |
-34% |
| Santa Rosa versus Core |
74% |
99% |
44% |
-44% |
更深层次的缓冲以及更加灵活的2x64-bit存取增加了读带宽，但是对于写带宽的增加可能还会起到反作用。这不是一个问题，每个周期获得54%的性能优势是一个巨大的优势。
还有一些anandtech无关紧要的说明在这里就不翻译了，下面发表一下我自己的观点。从这些数据来看，就内存子系统来说，AMD的集成内存控制器的功能的强大优势大家早已经明白了，这里就不再重复地说了。需要说的是AMD的新的动态电源管理技术，从数据上看Barcelona相对之前的Santa Rosa提升了最高达54%，应该说这项技术是相当的有效的，增加了内存控制器的频率带来的带宽的增加是比较客观的。可以看出来在内存密集型的应用当中Opteron会占据比较大的优势。
64-bit Linux Java 性能: SPECjbb2005
SPECjbb需要的是优秀的整数计算性能以及超强的内存子系统，特别是，如果你测试了我们所使用的一些例子，那些整数方面的提升会帮助Barcelona呢？使用32byte而不是之前的16byte得取数据带宽会让解码的速度较之平均速度有些需的提高。但是这只能在CPU计算每个周期多个指令的情况下才会提高性能，SPECJbb就是这样类型的应用程序（IPC大概在0.2-0.5之间）。
AMD的乱序算法，也就是将某些读指令放在写操作之前执行对于整数代码特别是存取内存次数比较多的代码来说有很大的性能提升。这个特性再Intel的Pentium Pro时代就拥有了，但是AMD直到现在才加入。这项特性让AMD的Barcelona比以前多了更多的“乱序”，Inte的Core构架在这项特性上拥有更多的灵活性。但是在SPECJbb测试中，考虑得更多的还是内存带宽的增加。
SPECjbb2005评测的是服务器端Java的性能，他模拟了3层服务器/客户系统，重点放在了中间层。为了避免使用依靠磁盘性能的数据库系统，SPECJbb使用了Java Collections创建的对象表。SEPCJbb的成绩依靠被测试系统的一下性能的强弱：
The JVM (Java Virtual Machine Java虚拟机)
CPU处理能力
Cache和内存的速度
Multiprocessing configuration (Scalability)
我们的目的并不是要显示我们的测试分数有多么的高，只要花一些时间来优化它们的JVM，就有可能获得高于这里的分数。所以我们在测试中选择了在各种系统中更为普遍的调节赖作为测试标准，JVM使用的是Sun的version 1.5.0_08。我们测试了SPECJbb2005的四个应用程序，并且使用了NUMActl这个工具将每个Java应用程序分配到独立的节点。但是在Intel平台上我们不这么做，因为这样可能会导致更低的性能。下面是我们的调节参数供大家参考：
On the Opteron we used:
numactl --cpunodebind=$node --membind=$node -- java -cp jbb.jar:check.jar -Xms2g -Xmx2g -Xmn1g -Xss128K -XX:+AggressiveOpts -XX:+UseParallelOldGC -XX:+UseParallelGC spec.jbb.JBBmain -propfile SPECjbb.props -id $x
On the Xeons we used:
java -classpath jbb.jar:check.jar -Xms2g -Xmx2g -Xmn1g -Xss128K -XX:+AggressiveOpts -XX:+UseParallelOldGC -XX:+UseParallelGC spec.jbb.JBBmain -propfile SPECjbb.props -id $x
新的Opteron（2350）非常出色，性能与2.4G的Clovertown相当，但是还是落后了老的Opteron 880,这主要是因为带宽特别是20%的CPU频率方面的差距。不过在注重内存子系统的SPECJbb2005的测试中，AMD还是理所当然的获得了绝对的领先，这也让我想到了为什么AMD对于采用新的内存总是采取一种保守的态度。原因有两个，首先就是AMD本身因为有了集成内存控制器技术已经在内存子系统方面取得了相当的领先优势，再有就是关键的价格因素，DDR3相对于DDR2来说的价格的劣势是非常明显的，AMD的整套系统不能因为一个内存而丧失了由于CPU的低价格带来的性价比。正是基于这样的两个原因，很好地揭示了我在今天上午的新闻中提到了AMD的Barcelona在内存控制器的设计中已经可以支持DDR3,但是现在在各种宣传中却一直没有提到的原因。
|
对 第8楼 ccred 说：