ところでキャッシュについてもう一つだけ。プレビューでSandraのMulti-Core Efficiencyを掛けた結果は異様に良かったが、HT有効時はともかく、HT無効時にはガクンと性能が落ちていた。ということで、これをもう少し見てみたい。
グラフ57は、改めて今回の環境でInter-Core Efficiencyを行った結果である。
|
Nehalem MAの成績はHTを有効にするとLatencyは少ないし帯域は大きいしでいいこと尽くめであるが、HTを無効にすると成績が落ちる事が改めて確認できた。実際、HTが無効の状態においては、Nehalem MAはCore MAと比較してBandwidth(棒グラフ)は下回り、Latency(折れ線グラフ)は上回るという結果になっている。
ただ、面白いのはDetail(グラフ58)を見た場合だ。
|
Previewでも触れたが、Phenomの結果を彷彿させるようなグラフとなっている(テストのバージョンや動作周波数など環境が異なるので、単純に数値を比較しても仕方が無い事に注意)。これは、大量のデータ移動には不向きではあるが、逆に言えばどのコアと通信する場合でもスループットやLatencyに差が無い事を意味する。
そこで、以前のPhenomのテスト同様に、Util35を実施してみた。Util35の趣旨やプログラムソース、プログラムイメージなどはこちらを参照してほしい。
|
|
|
|
さて、結果である。流石にHT有効の場合をこれ以上行ってもあまり意味が無いので、HTは無効のままとしている。まずグラフ59～62に、CPU別の結果をまとめてみた。転送サイズが大きくなるほどContext Switchingの頻度が減ることもあって所要時間が減ることはいずれの場合も同じだが、Core MAは256Bytesから1KBといった比較的サイズが小さい転送でグラフがバタつくのは判る。この理由は、以前のPhenomのテストの場合と同じであろう。
このあたりをもう少し判りやすくするため、256Bytes/4KB/64KBでのプロセッサ毎の結果をまとめたのがグラフ63～65である。
|
|
|
グラフ63で64bitにおけるCore MAのブレが大きいのは、Processor Affinityの割り当て方が32bitの場合と異なるためだろう。逆にNehalem MAではブレが殆ど無く、ほぼ均一になっているのは、Processor Affinityの割り当て方が変わっても差が無い(Core MAでは同じダイ上のThreadか異なるダイ上で動くThreadかでレイテンシが激変するが、Nehalem MAはダイが共通なので、どのコアで動いても差が出ない)事に起因する。さて、そうした話はともかくとして、256Bytesといった小サイズであれば、Nehalem MAはCore MAより高速化していることが見て取れる。動作周波数は異なるが、Phenomでも8Thread時に19秒程度要していたのが15秒ほどで済んでいるわけで、これはなかなか画期的である。
その一方、4KBあるいは64KBといったサイズになってくると、これはCore MAの方が高速である。やはり共有L2で通信できるのと共有L3で通信するのでは、Latencyが変わるのは仕方ないところであろう。逆に言えば、そうしたLatencyの大きさを踏まえてもまだ、小サイズのデータ交換であれば(Phenomや)Nehalem MAの方が適していると考えられる。
以下はこちらの最後にも書いた話であるが、やはりContext Switchingの負荷が掛かった時に性能が劣化しにくくなったのは間違いなく、このあたりはNehalem MAがCore MAよりもサーバー向けに性能の方向性を振った部分だと考えて良いと思う。
