テスト結果
さて、それでは実際にテスト結果を見てゆきたい。ちなみにテストの条件であるが、特に記述が無い場合、
Core i7:
・Hyper-Threading有効
・DDR3-1067×3ch
・500GB SATA HDD×2 (RAID0)
Core 2:
・DDR3-1333×2ch
・500GB SATA HDD×2 (RAID0)
としている。「折角XMPメモリなのにDDR3-1600ではないのか?」と思われるかもしれないが、DDR3-1600で動作させると軽負荷時は問題なく動作するのだが、重負荷時にはしばしばハングアップやリブートを繰り返しており、安定したデータが取れなかったからだ。
■Sandra 2009 Engineer Edition
SiSoftware
http://www.sisoftware.co.uk/
定番のSandraだが、早くも2009にVersion up。SSE 4.2への対応などまで終わっているという準備の早さだ。このSandra 2009でも少しテスト項目が変わったり、テスト結果の出方が変わったり、また新テストが追加されていたりするので、この辺りにも触れながら結果を見てみたい。
|
まずArithmetic Benchmark(グラフ1)だが、これはDhrystone/Whetstoneの実施。従来.NETやJavaでは出力結果がMIPS/FLOPSでなかったが、これが統一されたのが一つ目の違い。もう一つは早くもDhrystoneがSSE 4.2に対応したこと。もっとも、Dhrystoneのどこで使ったのか、はいまいち良く判らない。さて結果を見ると、これはもう圧倒的である事が判る。Hyper-Threadingの効果もあるのだろうが、特に浮動小数点演算での性能向上が著しい。.NETやJavaといった仮想マシン環境でも大きく性能が伸びているのは、やはり地力がそれなりに伸びていることの証でもある。
|
これはMulti-Media Benchmark(グラフ2)でも見て取れる。おなじみマンデンブロ図形の描画だが、今回からFloatに関しては単精度/倍精度を分けてテストするようになった関係でやたらと項目数が増えている。結果はMpixel/sに統一された。こちらの結果でも、やはりCore i7の性能の伸びが目立つ。殆どのテストでCore i7-920がCore 2 QX9770を凌駕しており、動作周波数の差(2.66GHz vs 3.20GHz)を考慮すると、20%以上の性能の伸び、と思わず結論づけてしまいたくなる。
|
ただ、そういい事ばかりでもないという結果がグラフ3のCryptography。暗号化処理のベンチマークでSandra 2009から追加されたものだが、AES256でもそれほど大きな伸びではないし、SHA256に至ってはCore 2に遅れをとる結果になっている。
|
そこでSHA256に関して環境を変えてみたのがグラフ4である。RAID 0を構成したままHyper-Threadingを有効/無効にしたケースと、Hyper-Threading有効ながらSSDを使ったケースだ。結論から言えば、Hyper-Threadingを無効にすることで、Core 2と同等の性能になっていることが判る。ちなみにこのテストではSSE 4.2のPOPCNT命令を使っており、それを持ってしてもCore i7とCore 2は同等ということだ。
|
気を取り直して次はInter-Core Efficiency。流石に4コアをオンチップで結合し、共有L3を搭載しているだけの事はあり、帯域(棒グラフ)はCore 2の倍以上、Latency(折れ線グラフ)は半分未満(というか、3分の1近く)という優秀なものになっている。
|
ただ詳細(グラフ6)を見ると、明確にCore 2とは傾向が異なっている事が見て取れる。特に小サイズのデータ交換が大幅に高速化されている「様に見える」。何でかといえば、これはSandraの問題。テストにおけるProcessor Affinityが"CPU0-CPU4 CPU1-CPU5 CPU2-CPU6 CPU3-CPU7"と割り当てられているからで、これは要するに1つのコアを共有する2つのThread同士でデータ交換してるだけである。
|
なるほどこれならば高速な訳であるが、実際の性能がどうかというのはまた別の話になる。では、Hyper-Threading無効の場合はどうか? というのがこちら(グラフ7)。この結果を見て連想するのが、PhenomのMulti-Core Efficiencyである。このあたりは、後ほどもう少しちゃんと調べる必要があるだろう。
|
次にキャッシュとメモリ廻りである。まずグラフ8はBandwidthである。概ねセオリー通りというか、L2キャッシュの帯域がかなり大きい事が見て取れる。これはサイズが1MBあたりの結果を見れば判りやすい。一方このグラフだとMemory Bandwidthが流石に読めない。そこで256MBの場合だけを抜き出したのがグラフ9である。
|
一応環境別にしてみたが、殆ど環境に差はなく、概ね倍以上の帯域が利用できることがわかる。理論的にはCore 2が1333MHz×8Bytes×2ch＝21.3GB/secということになるが、実際はFSBの1600MHz×8Bytes＝12.8GB/secで制限されており、一方Core i7は1066MHz×8Bytes×3ch＝25.5GB/secとなるが、1つのコアでこれだけ使いきれる訳ではないから、どちらも妥当な数字ではないかと思う。
|
|
最期にLatencyであるが、Linear Accessの結果をグラフ10に、Random Accessの結果をグラフ11に示す。結果をみると、ことL1に関してはLatencyが3→4とやや悪化しているが(パイプライン構成がやや変わったことも無縁ではないだろうが)、L2に関しては13→10と大幅に減っており、L3も12程度でアクセス可能となっている。またMemory AccessのLatencyが10Cycle以上減っているのは、やはりMemory Controllerを統合した威力だろうか?
ただ、Random Accessとなるとあまり手放しで喜べないLatencyになってるあたりは、一つはこうした使い方では構造に起因するLatencyよりも、実際にアクセスに要するLatencyの方が支配的であるという意味でもあるが、特にL3のLatencyが大きいのはやはり8MBものキャッシュのRandom Accessにはどうしても時間が掛かってしまうということであろう。
