RightMark Memory Analyzer 3.8(グラフ15～59)

cpu.rightmark.org
http://cpu.rightmark.org/

さて、まずはD-Cache/RAM Bandwidthの結果をグラフ15～17にまとめる。ここで一見して判るのは、一貫して低い(?)、Zacateの帯域である。特にL1の領域において、Readで8Bytes/cycle、Writeで5Bytes/cycle、Copyで3.4Bytes/cyle程度の値でしかない。Readだけとってみてみても、Atomで15Bytes/cycle程度、Nanoですら11Bytes/cycle程度を維持しているから、これに比べると格段に低いと言わざるを得ない。ちなみにグラフ15～17はSSE2を使っての結果だが、MMX/SSEの場合もほぼ同じ結果になっており、単に命令の相性云々というよりはアーキテクチャ的な問題に思える。

面白いのはL2で、ことReadに関してはZacate/Atom/Nanoが全部3.5Bytes/cycleで横並びになっている。もっともWriteだとAtom/NanoがL2で4.2Bytes/cycle前後なのにZacateは3Bytes/cycleだから、あまり褒められたものではない。ただCopyをみるとNanoが一番帯域が低いというのは、L2のコントローラの問題なのか、NanoのLoad/Store Unitの問題なのか、にわかには判断しにくい。Memory Accessでは(開発元が一緒なだけあって)先ほどのRMMTとほぼ同じ傾向が見て取れる。

ついでにD-Cache/RAMのLatencyをまとめたのがグラフ18～21である。それぞれForward/Backward/Random/Pseudo-Randomの順にまとめたものだが、とりあえずMemory AccessでNanoが大変にLatencyが大きい事はまぁ措いておくとして、L1に関してはどのアクセスパターンでも、

Zacate : 3clock
Atom : 3clock
Nano : 4clock

で一定である。変わるのはL2以降である。まずL2に関しては(Randomを除くと)、

Zacate : 20clock
Atom : 17clock
Nano : 24clock

というあたりに収まっており、Randomの場合はどのCPUも概ね25cycle前後で大差ない。NanoのLatencyがやや多いのはExclusive Cacheの構成をとっているためだろう。ここまではAtomが非常に優秀である。ところがその先のMemory Accessに関しては、Zacateが非常に優秀な成績を収めている。

実のところこのLatencyの低さと、先に示した帯域の少なさがどうもあんまりうまくマッチしない気がする。ここからは筆者の推定であるが、ひょっとしてZacateのメモリコントローラは、内蔵GPU向けに帯域の一定部分を確保しており、残った分がCPUに割り当てられているのではないか? という気がする。Photo41はグラフ15～17の結果のうち、Zacateの分を抜き出したものだが、L1～L2はともかくMemory Accessでこんなに帯域が一致しているのを見たのは初めての経験である。SDRAM自身が、そもそもReadはまとめて行えてもWriteはずっと遅くなるデバイスだから、普通はこんな風になる事はありえない。ということは、Memory Controllerがコアあたり1.5Bytes/cycle(というか、絶対的な帯域として2.4GB/sec前後)を上限とするように、特にReadの帯域を絞っているのではないか? と考えられる。

Photo41: というか、RMMAは本来こんな風に、1つのCPUの結果をまとめてグラフ表示&CSV出力が可能で、あとで手作業でテスト別に複数のCPUの結果をまとめたのがグラフ15～17である。