Sandra 2011 Engineer Edition(グラフ1～22)

SiSoftware
http://www.sisoftware.co.uk/

さて、まずは定番Sandra 2011である。グラフ1がDhrystone、グラフ2がWhetstoneであるが、これはいくらなんでも...というほどにSandy Bridgeのスコアが高い。動作周波数はCore i7-975が3.33GHz、Core i7-2600Kが3.4GHzだから、それほど大きな差ではない。勿論Turboの効き具合が異なる、という話はあって、45nmプロセスのNehalemと32nmプロセスのSandy BridgeではSandy Bridgeの方が熱的に有利な可能性はある。ただCore i7-975はTDPが130W、Core i7-2600KはTDPが95Wだから、これを勘案するとどちらもDhrystone/Whetstoneの様な全コアに負荷がかかりやすいケースではTurboの効果はそれほどないと考えるのが無難で、つまりこれは純粋にコアの性能が改善した、と考えるのが妥当だ。ちなみにCore i5-2500Kのスコアが低いのは、こちらはHyper-Threadingが無効だからであり、逆に言えばこれを有効化してもALUでの性能差は殆どない(FPUはまだ効率が悪いためか、随分性能の伸び代があるが)ことが見て取れる。こうした傾向は、Multi-Media Benchmark(グラフ3)でも見て取ることができる。

ただCryptgraphy(グラフ4)に関しては、これはCore i7-975がAES命令をサポートしていないので大差がついているが、逆にSHA256のHasingでは僅差ながらCore i7-975がリードしているなど、アプリケーション次第ではSandy Bridgeのメリットが殆どないケースも存在することは確認できた。

次のMulti-Core Efficiency(グラフ5)に関しては、まぁi5-2500Kのスコアが低いのはHyper-Threadingが無効なためで、これは不思議ではない。むしろ気になるのは、i7-2600Kが帯域はともかくLatencyが増えている事で、やはり4ブロックに分割したL3が効いているのかもしれない。ということでグラフ6がDetailだが、帯域だけみるとむしろ16KB程度のデータ交換でピークがやや伸びない傾向があり、このあたりが効いている可能性もある。まぁNehalemから大分このあたりをいじっており、そのため異なる傾向を示すということだろうか。

グラフ7はCache&Memoryで、明確にNehalemよりも高いバンド幅になっていることが見て取れる。少なくともL3(or LLC)が有効である4MB近辺まで、これは明白である。ではL3 Missとなる領域は? ということでグラフ8がSTREAMの結果である。Int/Floatの両方のケースで、明らかにSandy Bridgeの帯域はNehalem世代を上回っている事が判る。メモリの帯域そのもので言えば、先のベンチマーク環境のところで述べたとおりCore i7-975が圧倒的に上である。効率で言えば、理論帯域25.6GB/secのSandy Bridgeが80%以上の効率を叩き出しているのに対し、Core i7-975は50%にも満たない程度でしかない。これは間違いなくコア側の(特にIMCの)性能改善と思われる。

帯域は良いとして、ではLatencyは? ということで、まずグラフ9はL1/L2/L3のLinear Access/Random Accessの平均値をまとめたものだ。Linear、つまりSequential Accessに関しては、L2以降ではやはりSandy Bridgeの値がやや悪化している。ところがRandom Accessの場合、特にL3におけるLatencyが大幅に減っているあたりは非常に興味深い。もう少しこれを仔細に見たのがグラフ10・11である。Linear Access(グラフ10)の場合、Memoryは別にするとほぼ全域でCore i7-975が低めに収まっている。この差は割と明確で、誤差とは思えないあたり、L3(LLC)のみならずL2(MLC)にも手が入っているのは間違いない。この傾向はRandom Access(グラフ11)の場合も明確で、やはりL2 Hitの範囲まではCore i7-975の方が高速である。ところがLLCのアクセスに関しては明確にSandy Bridgeが有利ということで、これは非常に興味深い。

ということでまずは一通り比較が終わったところで、次にCore i7-2600Kを使い、AVXの性能比較をしてみたい。まずはDhrystone/Whetstone、と言いたい所だがまだSandraのDhrystone/WhetstoneはAVXに対応していないため、今回は見送りである。その代わりといっては何だが、Multi-Media BenchはAVXに対応している。このテストの場合、

SSE4.2 AVX
Integer x16 x32
Float x8 x16
Double x4 x8

として処理を行う。ということで結果であるが、グラフ12の通り面白いことになった。以前触れた通り、AVXの拡張にあたって実行ユニットのデータ幅そのものは増やされていないし、AMDのBulldozerの様に、2つの実行ユニットを連動させることで256bitのデータを同時に処理するといった仕組みはない。このため、AVX命令を使う場合には原則として128bit幅の同等命令の倍の時間が掛かる事になる。Integerの結果がまさしくこれで、1命令で処理できるデータ幅は倍ながら、かかる時間も倍なので、結果として性能には大差ないという結果に終わっている。ところがFloat/Doubleではほぼ倍近い演算性能になっている。これは何かといえば、FPUのレイテンシの大きさに起因すると思われる。もともとFPU命令にせよSSE命令にせよ、浮動小数点演算は処理のレイテンシが大きい。しかも前後にデータ移動も入るから、浮動小数点演算でピーク性能を出すのは基本的には容易ではない。ところがAVXを使うと、黙ってても最低でも2命令は連続して実行されるから、SSEなどに比べて効率を上げやすい。しかももともとレイテンシが大きいから、2回演算することによるレイテンシ増加はそれほど目立たない。結果、IntよりもFloatが高速という、あまり見ない結果になったと思われる。この考察が正しければ、第一世代のAVXに関しては、整数演算ではそれほど効果はないだろうが、浮動小数点演算の高速化には効果大、といったところになると思われる。

もう一つAVX命令関連でCryptographyの結果をグラフ13に示す。このテストの場合、SHA256のみAVXを使っているが、やはり整数演算とあってかそれほど効果が見られない。逆にAES256ではむしろ性能が下がっているが、これはOS内部でレジスタが256bit対応になったことで、むしろレジスタ退避/復帰のオーバーヘッドが増えた事で性能が下がったのではないか、という気がする(このあたりはもう少し中身を見てみないと断言しにくい)。とりあえず整数演算では殆ど効果なし、とは言えそうだ。

次に、H67/H57プラットフォームの性能差を比較してみたい。ベンチマーク環境のところで述べたとおり、Core i5-670+H57 vs Core i5-2500K+H67 という構成での対決になるわけだが、Core i5-670は3.47GHz駆動とは言え2コアのHyper-Threading、Core i5-2500Kは4コアの3.3GHz駆動なので、CPU性能そのものは初めから話にならない。ここで比較したいのは、UMA方式でメモリを共用する関係で、どれだけメモリアクセス性能が落ちるのかという点と、GPUコアの性能である。

ということで、まずはMulti-Core Efficiencyをグラフ14に示す。面白いのはi5-2500Kで、Latencyは内蔵GPUの場合もDiscrete GPUの場合もほぼ同等なことだ。とはいえ、Memory Bandiwdthは0.6GB/secほど削られる。これをもう少し仔細にみたのがグラフ15である。ピークが異なっているのは先のグラフ6と同じなので良いとして、とりあえずCore i7-2500K同士を比較すると、やはり内蔵GPUを利用すると全体的に多少オーバーヘッドが発生することは否めないようだ。

純粋にキャッシュ/メモリアクセスを行った場合は? というのがグラフ16で、やはり微妙ではあるが、明確に差がついているのが判る。一番気になるメモリアクセス性能は? というと、グラフ17で示す通り4GB/secほどの差となる。今回の場合、テストはWQXGA(1920×1200pixel)、60Hz、24bitカラーだから、約400MB/sec程度の帯域が最低でも画面リフレッシュのために利用される計算だが、流石にこれでは効かなかったということだ。ただ、もともとの帯域が高いから、4GB/sec引いてもまだ17GB/sec残っており、11GB/sec程度のCore i5-670とはかなり明確な差となる。

ついでにLatencyもOverallのみグラフ18に示すが、意外に内蔵GPUを使う/使わないではLatencyに差が出ないことも確認できた。

最後がGPU周りである。とはいえ、Core i5-670に内蔵のIntel HD Graphicsはもとより、Core i5-2500Kに内蔵されるIntel HD Graphics 3000もかなり制約は多い。一応Direct3D 9c/10/10.1のテストは通ったが、今回利用したドライバではOpenGL系は全滅だったし、いくつかのテストは正常に動作しなかった。そんなわけで、動いたものだけPickupする。

まずグラフ19がVideo Renderingである。Core i5-670のIntel HD GraphicsはDirect3D 10/SM 4.0対応なので、Direct3D 10.1対応のテストは動作しなかったため、"N/A"としている。さてスコアを見てみると、倍とまではいかない印象である。ことシェーダーの性能に関して言えば、性能が5割増という程度に考えておくのが無難そうだ。一方のメモリアクセス(グラフ20)だが、こちらでは何故かCore i5-2500KでDirect3D 11のAPIが通ったため、テスト結果はDirectX 10/10.1/11の3種類、一方Core i5-670はDirect3D 10のみとなっている。とはいえ性能そのものはどのAPIを使っても大差ないようだ。さてその結果だが、こちらも倍とはいえないが、内部メモリへのアクセスは30%高速化、PCIeのRoot Complex経由でのアクセスは50～70%高速化といったところだが、確かに高速になったといえばなっているのだが、本来のSandy Bridgeの構成ならばRingBus経由でGPUから直接LLCにアクセスできる筈である。ただこれが実現していればもっと高速に動作する筈で、この程度のスコアというのはLLCへのアクセスの際に、一度GPUからSystem Agent経由でRoot Complexにリクエストを出し、Root ComplexがSystem Agent経由でメモリアクセスリクエストを出すといった二度手間を踏んでいるためと思われる。勿論これはソフトウェアの互換性を保つためには必須である。現状、Sandy BridgeのGPUコアはCache Coherencyを維持する仕組みはどうも持っていない風情であり、またドライバのみならずアプリケーションの側もGeneseoとして定義されたPCIeのProtocol Extentionを使わないと、直接キャッシュアクセスは出来ないはずである。このあたりのソフトウェア互換性を保つために、いやでもRoot Complexを経由しているものと考えられる。

あと、一応GPGPU Processingの結果(グラフ21)とGPGPU Memory Bandwidth(グラフ22)の結果も示しておくが、こちらは動作したのがCore i5-2500Kのみなのであまり意味の無い数字となっている。ただまぁこれは性能云々の前に、まず動いた事が確認できた、という意味合いが強い(実際、Core i5-670ではテストが動作しなかった)訳で、とにかく動いたことを評価してもよいだろう。