さて帯域は確認できたがLatencyは? ということで、グラフ31～34がI-Cache/RAM Latencyの結果である。全体を通してまず気になるのは、L2の範囲で若干LatencyがPhenom IIより増えていることだ。ただこれはL2の容量が倍になり、ところがAssociativityが同じ16wayなので、Hit/Missの確認に余分に時間が掛かるためと考えられる。このあたりはキャッシュを大容量化すると避けられない事柄である。むしろ問題なのは、1MBを超えてからのLatencyの急速な悪化である。もちろんこれは6MBのL3 Cacheを持つPhenom IIが圧倒的に有利であって、こうした差になるのは仕方ないところで、この先更に大きなデータサイズになるとPhenom IIでも悪化するのだが、その悪化の仕方がちょっと違う。たとえば32MBにおけるForward ReadのLatencyは、

Phenom II 43.43cycle
Llano(補正前) 100.33cycle
Llano(補正後) 93.54cycle

といった数字になっていて、確実にLatencyが増えているからだ。もっとも32MBにおけるRandom ReadのLatencyは、

Phenom II 185.26cycle
Llano(補正前) 210.21cycle
Llano(補正後) 196.11cycle

ということで、その差はごくわずかだったりする。もちろんGPU周りのメモリ制御が追加されたりしているので、Latencyが増えるのはやむをえないが、Random AccessなどLatencyが性能にインパクトを与えやすいケースでの増加を抑えるような配慮がなされているように感じる。

面白いのは次のD-Cacheのケースだ。グラフ35～38がD-CacheのLatencyであるが、L1 Accessの時点で既に1cycleほどPhenom IIより低く、L2領域では更にその差が広がっている。また1MBを超える領域でも、Phenom IIよりも確実に高速である。たとえばグラフ31とグラフ35を見比べていただくとこれは判りやすい。Phenom IIはほとんど同じだが、LlanoではI-CacheのLatencyは大きく、一方D-CacheのLatencyは圧倒的に小さい。

個人的には、このあたりがLlanoの真骨頂なのではないかと思う。Llanoの場合、CPU-GPUの融合がメインテーマで、なのでGPUとCache Coherencyが維持されているほどだ。こうなると、Data Cacheのアクセスは迅速に行わないと性能が出ない。ただこれは当然ながらData Accessであって、Instruction Accessではない。Instructionの方は、そもそもL1が低Latencyで動作すれば十分であって、L1 Missを起こすようなケースではLatencyが多少増えても、Data AccessのLatencyが同じだけ増えるよりはずっと影響が少ないと考えられる。こんな具合にLatencyのPriorityをつけたのがLlanoではないか、と筆者は考えている。これはZacateのように帯域そのものを固定的に分割するよりずっとソフィストケートされた方法である。おそらくL2アクセスの命令キューで、最優先に処理されるのがData L1やCache同士のDirect Connectで、次がGPUからのAccess、一番優先度が低いのが命令L1といった形になっているのだと思われる。