さて、そこで次はLatencyである。まずグラフ45～52は、I-Cache/RAMのLatency測定である。尤もI-Cacheといっても、L2以降はUnifiedなのであまり意味はないのだが。さて、まずLatencyそのものを比較してみる。

大雑把に言えば、Sequential Accessを行っている場合は、ほぼ全てのケースでNehalem MAのLatencyはCore MAを下回っている。例えばグラフ45の場合、実際のLatencyの値をいくつか抜き出したのが表4である(単位はcycle)。

L1の領域でも微妙に高速化されている(概ね2cycleを微妙に切る程度)し、L2は容量こそ小さいが12cycle程度だから、Core MAの半分である。これを超えると多少Latencyは増えるが、それでも13cycle程度だから、かなり優秀な部類に入ると思ってよい。ただ、これはNear Jumpの範囲なので、もう少し広い範囲に分散するとどうなるか、ということでグラフ49の値を抜き出したのが表5である。今度はさすがにL2やL3でも一発Hitという訳にもいかないようで、L2～L3で全般的にLatencyは増えているのがわかるが、それでもやはりLatencyが大幅に減っていることが判る。

例外があるのはRandom Readの場合。グラフ47とか51で、この場合のL3のLatencyはCore MAに比べるとやや大きめ(というか、次第に増えてゆく)のが判る。またPseudo-Randomの結果(グラフ48、52)でも、Core MAのL2とNehalem MAのL3は概ね同等のLatencyであり、ここから考えるにSequential Accessの場合はHardware Prefetchがうまく動作して低Latencyでアクセスが可能だが、これにHitしないと生の性能がそのまま出てしまうというあたりではないか、と想像される。グラフ47・51でNehalem MAのLatencyがどんどん悪化しているのは、8MBという大容量にも関わらず16-way associativeであること(Core MAの場合、4MBのConroeで16-way、6MBのPenrynでは24-wayである)が関係していそうだ。もっとも、assosiativityを増やせばいいというものでもない(あまり増やしすぎると、最小Latencyそのものが増加する)から、このあたりはバランスの問題なのだろうが。

この傾向がもう少し助長されるのが、D-Cache/RAMのLatency測定(グラフ53～56)である。

このうち、グラフ53の数値を幾つか抜き出してみたのが表6だ。

L1の場合、Core MAは平均3cycleなのに対してNehalem MAでは3.7cycleといったところ。Core MAのL2は平均8.9cycle程度で、Nehalem MAはL2こそ7.3cycleだがL3は9.1cycleといったあたりで、概ね同等かちょっと遅いといったあたり。Prefetchは命令には効果的に作用しても、データにはやや効きが悪いというところかもしれない。とはいえ、L1に関してはこの程度ならバンド幅でカバーできる範囲だし、L2はCore MAより高速、L3もほぼ同等だから、少なくともここでデメリットは無いと考えられる。むしろ256KBと小型化したとは言え、L3よりも高バンド幅、低レイテンシのL2があるために、小さなプログラムではむしろ高速に動作する可能性の方が高い(大きなプログラムは、今度はメモリ帯域の問題になるからだ)。この傾向はグラフ55のRandomや、グラフ56のPseudo-Randomでも大枠では変わっておらず、Nehalem MAのキャッシュ構造の優秀さが確認された結果になった、と言える。