I-TLB Associativity(グラフ49～72)
I-TLBでもう一つ、Associativityも。先ほどのI-Cache Assosiativityと同じく、構成としてはIvy Bridge/Haswell共にL1が4-way、L2が8-wayというのは既に判っているのだが、これを超えてアクセスが来たらどうなるか、を見たものだ。テストはNear Jump/Far Jumpそれぞれについて、16/32/64/128 EntryをForward/Backward/Randomで試している関係で2×4×3＝24枚もグラフが出現しているのはご容赦いただきたい。
さて結果は非常に判りやすい、というかちょっと面白いものだった。まずNear Jump, 16 Entry、Forward(グラフ49)を典型例としてみてみたい。Ivy Bridgeのそれは4-wayらしく、4 pointまではLatencyが低いがそこから急増する。ではHaswellは? というと、なぜか8 pointまで低いLatencyが維持され、8 pointを過ぎてもLatencyの絶対値はIvy Bridgeよりも10cycle以上少なく収まっている。この傾向はBackward(グラフ50)、Random(グラフ51)なども共通である。
では、よりEntry数が増えるとどうか? ということで32 Entry(グラフ52～54)を見ると、更にギャップが増えているのが判る。もっとも、ではこの差は更に開くのか? というと、64 Entry(グラフ55～57)ではほぼ16 Entryの結果を横に伸ばしたような構図になり、128 Entry(グラフ58～60)でも結果が多少荒れているものの、ほぼ同様の構図になる。Far Jumpの結果(グラフ61～72)も、ほぼNear Jumpと同じ傾向を踏襲するものとなっている。
これはどういうことかであるが、HaswellではTLBの利用方法にちょっと細工を加えている気がする。Ivy Bridgeまでは素直に最初の4 PointまではL1 I-TLBにHitするが、ここでMissするとL2 TLBの参照に移動する。ところがHaswellの場合、なるべくL1 I-TLBを使うような工夫をしているように見える。32 Entryのときに妙にLatencyが少ないのもこれを示唆しており、4-wayを超えて同じEntryになるアドレスを保持できるような細工が成されているように見える。このあたりは、先ほどDecodeのところでμOp Decode CacheのTagがちょっと一工夫されていることとも共通する。なるべく高速なバッファ(μOp Decode CacheとかL1 I-TLB)をぎりぎりまで使えるような工夫をすることで性能を高めよう、という配慮ではないかと思う。
次ページ：RMMA 3.8 - D-Cache/RAM Bandwidth
