D-TLB(グラフ73～81)
ではD-TLBは? ということで、Trinityの時の結果はこちらである。ZambeziのD-TLBの構造は、これも以前説明したとおり、L1 D-TLBが32 EntryのFull Associativity、L2 D-TLBが1024 Entryの8-way Set Assosiativeである。
さてまずグラフ73～75がD-TLB Sizeの結果であるが、まずL1 D-TLBに関しては確かに倍増しているようで、FX-8150が32 EntryでL1 D-TLBがFullになっているのに対し、FX-8350では64 Entryまで4cycleでアクセス可能となっている。その先はL2 D-TLBにアクセスという事になり、こちらはどちらも256Entryあたりまで踏ん張るものの、そこでL2 TLB Missとなっているようだ。なんで1024ではなく256なのかは謎だが、これはRMMAのアドレスの取り方の問題なのかもしれない。ただこの傾向そのものは、FX-8150でもFX-8350でも変わらないから、TLBのサイズそのものは同じと考えてよいだろう。
不思議なのは、L2 D-TLBのアクセスがFX-8350で遅くなっていることだ。これはどのケースでも共通なので間違いではなく、そういう仕様なのだろう。Trinityの時には「これはL1 TLBのEntryを増やした分、Hit/Missの判断に余分に時間が掛かっているというあたりではないかと思う(このあたりは補正データではなく元データで見るのが正しいように思う)。」としたが、やはりそういう理由なのではないかと思われる。ちなみにL2 D-TLBをMissした場合のLatencyはFX-8150とFX-8350の間で大差はなく、なのでやはりTrinityの際に書いた「L2 TLB Missの場合のLatencyも、(補正データと元データのどっちで判断するか、によるのだが)おそらく多少高速化されているのではないかと思える」は間違いであったようだ。
ただ、D-TLBのAssosiativityについてはちょっと面白い結果になった。16 Entry/32 Entryに関しては、Latencyが全部4cycleということで一定だったのでグラフを省き、64 Entry/128 EntryのForward/Backward/Randomについてグラフ76～81に示したが、とりあえず64 Entry(グラフ76～78)に関してはFull Assosiativeで全Entryを保存できるFX-8350が常時4cycleなのは当然として、FX-8150が予想外に暴れているのがちょっと気になるところ。
逆に128Entry(グラフ79～81)では、最初の8EntryではFX-8150の方がLatencyが少なく、その後はFX-8350の方がやや少ないLatencyになるという対照的な構図になっている。
ここから察するに、TLBアクセスの基本的な構造そのものには手が入っていないが、I-TLBの場合同様に検索速度が向上した結果として全体的にややLatencyが削減されており、ただL1 D-TLBはEntry数倍増によるLatency増加が仇となってFX-8150よりもややLatencyが増えている、というあたりなのではないかと思う。
次ページ：RMMA - Stream
