さて、前書きが長くなったので結果である。グラフ38~40が、RMMAのMemory Bandwidthテストを使った、Read/Write/Copyのスループットである。この数値はあくまでシングルコアによるもので、全コアで一斉にテストを行った結果ではない。

まずグラフ38から明らかなように、1KB~32MBの全ての範囲で、Nehalem MAはCore MAを上回る帯域を維持していることが見て取れる。もっとも、例えばWriteの場合、L3の領域ではかなり数値がバタついており、このあたりは確率的に多少性能がバタつきやすい事を暗示しているようだ。

ちなみに全コアを使った場合はどうか? ということで、グラフ41にSandra 2009のCache&Memory Bandwidthの結果を示す。

グラフ38だと、1コアあたりのピーク値が55GB/secになるから、4コア合計だと440GB/secあたりになってもよさそうなものだが、最高でも320GB/sec程度に納まっているのは、利用するプログラムの違いにあるのかもしれない。

ところでグラフ38~40、ちょっとこのままだと判りにくいので、1cycleあたりのスループットに変換したのがグラフ42~44である。

ここで改めて判ったのが、L1キャッシュの帯域が17Bytes/cycleを超えていること。グラフ42でピーク値は17.2Bytes/cycle、グラフ43では17.3Bytes/cycleにも達しており、グラフ44のCopyですら17.2Bytes/cycleに達している。Core MAはRead/Writeで16Bytes/cycleに満たない程度、Copyでは13Bytes/cycle強でしかないことを考えると、ここに手が入っていることは間違いない。

まずCopyに関しては、Store Bufferが大幅に増やされた(20→32)事と、その一方でCore 2に搭載されていたWrite Combining(WC) Bufferがこっそり廃止されていることも何かしら関係あるのかもしれない。

表3は、Core i7の発表と同時に更新された"Intel 64 and IA-32 Architectures Software Developer' s Manual Volume 3A:System Programming Guide, Part 1"のChapter 10に示されている、キャッシュとバッファのスペックをまとめたものだ。

なぜかCore i7はWC Bufferに関する記載がなくなっている。開発時期的にはCore MAとNehalem MAの間にあたるAtomで、WCがStore Bufferと共用になっていることや、Nehalem MAがStoreユニットを2つに増設したあたりを考えると、Store BufferとWCを設けるよりもStore Bufferで全てまかなうという判断を下したとしてもそれほど不思議ではない。