ついでに、Previewでは省いたMulti-Core Efficiencyの結果も示しておく。グラフ07がOverallであるが、やはりL2のLatencyが効くためか、全般的にKentsfieldが優勢といった結果になっている。Bandwidthが棒グラフ、Latencyが折れ線グラフとなるが、やはりコア間での通信ではL2のLatencyが大きく影響していると言える。もっとも「大きく」といっても、Bandwidthで2%、Latencyで3%といったところだから、「大きく」は大げさかもしれないが。さて、グラフ08はグラフ07の詳細である。大きく差が付くのが2×32KBという、丁度L1にあふれてL2をアクセスし始めるあたりで、これが32bit/64bitを問わずYorkfieldがKentsfieldに大きく差を付けられいている部分だ。それ以上になると、はなっからL1ではあふれてしまうためか大差ない結果になっている。とはいえ、全般的にちょっとだけYorkfieldが低め、という結果である。

さて、Latencyの話が出てきたついでに、CPU-Zに付属するLatency Testを使った結果をまとめてみたい。何れも32bit環境で、3回取った結果を平均している。まずグラフ09が、KentsfieldとYorkfieldのLatencyの差をまとめたものだ。グラフはKentsfieldのLatency - YorkfieldのLatencyという形となっている。Sizeが小さい、あるいはStrideが小さい場合には両者に差は見られないが、大きくなるとYorkfieldのLatencyが(Kentsfieldよりも)大きくなる傾向がはっきり見て取れる。

そこで、比較的差の大きなStride=64/128/512の個別の結果を示したのがグラフ10～12である。どのグラフでも、64KB～2MBまではKentsfieldが平均1clock Latencyが少ないが、4MB/8MBについては圧倒的にYorkfieldが高速である。やはり6MBというキャッシュサイズはそれなりに効果的という事がここからも見て取れる。

なんでKentsfieldが4MBで悪化しているかといえば、これが共有L2キャッシュの構造をとっているために、4MBをまるまる1つのコアで使い切れないあたりが影響していると思われる。当然あふれた分はMemory Accessとなるから、その分Latencyが悪化するというわけだ。これは8MBの場合も同じで6MBフルは無理にしても5MB程度はL2キャッシュ、残りがMemory Accessとなる関係か、Strideが少ない(=64)時にはそれなりの効果が発揮されているようだ。

もっともある程度Strideが増えるともうどうしようもない、というわけでグラフ12では8MBでのスコアも殆ど違いが無い(厳密に言えば188.0:185.7だからYorkfieldがむしろ悪い事になるが、これは誤差の範囲だろう)のが判る。これらから言えることは、

  • 本当にWay数を増やしてキャッシュ容量を増やしただけ。
  • Way数が増えた結果、Latencyは1clock悪化。
  • Latencyの増加と容量の増加によるパフォーマンスへの影響は、この段階では未知数。

といったところだ。一般論として大きなデータを扱うような時には多少なりとも6MBの効果はありそうだが、L1 Miss/L2 Hitの範囲では性能が下がることになる。ただ、世の中のアプリケーションは多くがL1 Hitの状態で動いていることを考えると、実は大した影響はないという事で終わりそうな気もする。