D-TLB(グラフ61～75)
お次はTLBである。まずはData TLBの方からみてみよう。Bulldozerの場合、Photo02に示す通りL1 D-TLBが32-entryのFully Associatgive、L2 TLBが1024-entryの8way(Photo04)という構成になっている。
![]()
|
Photo04: 注意書きに在るとおり、このL2 TLBは命令とデータ、両方に対しての共有TLBとなっている。 |
さて、まず最初がSize Determination(グラフ61～63)であるが、AMD FXはどのケースでも32 entryまでの範囲は4cycleでアクセスできており、これがL1 D-TLBに相当するものと思われる。問題はその先で、フルに使えば1024 entryが利用できそうに思えるのだが、どのケースでも254 entryまでは24Cycleでアクセスできているのに、この後急激に悪化して40Cycleになっている。40Cycleというのは、先のグラフ29でも判るとおりMemory AccessのLatencyではないかと思われる。どうもこのL2 TLBは、命令とデータ共用で、しかも2コア間でも共用な様だ。そう考えると、1024-entryといっても実質的には256entry程度しか残らない事になる。TLBもInclusive構成になっているとすれば、248entryあたりでL2 TLBの利用が制限されてきても不思議ではないのかもしれない。そんなわけで、スペック上は結構潤沢に見えるD-TLBだが、実際にSingle Threadで使う限りはあまり潤沢とは言えない様に感じられる。LatencyがCore i7やPhenom IIと比較しても全体的に大きめなのも気になるところだ。
では実際にTLBをアクセスするとどうなるのか? ということで、16 Entry(グラフ64～66)、32 Entry(グラフ67～69)、64 Entry(グラフ70～72)、128 Entry(グラフ73～75)でのアクセスパターンをそれぞれ実施してみた結果を見てみたい。
まず16 Entryと32 Entryだが、この範囲ではL1 D-TLBにフルヒットするから、AMD FXは常に4 CycleでTLBアクセスが可能となっている。Phenom IIよりも1 Cycle多いとはいえ、これは妥当な成績で、むしろ妙に悪化しているCore i7が不思議なほどだ。
これが変わってくるのは64 Entry以降である。まず64 Entryの場合であるが、無理にL1 D-TLBにHitした場合とL1 D-TLB Miss/L2 TLB Hitとなる場合、およびL1/L2 Missとなる場合で極端にLatencyが変わるPhenom II(これはTLBもExclusive構成になっていることに起因する)と比較すると、Inclusive構成のAMD FXの結果は安定しているとはいえるが、Latencyが安定して55cycleも掛かっているのは、本当にL2 TLBが効果あるのかちょっと理解しがたいものがある。さすがに128 Entryの方は大分Latencyに変動が見られるが、それでも最小値は50 Cycle以上になっている。L1 Hitの範囲でも24 Cycle掛かってるところを見ると、32 Entryを超えるような同時アクセスがあると、TLBの検索に時間が掛かるためにLatencyの上乗せがある、という理解をすべきなのかもしれないが、だとすれば随分効率悪い仕組みである。L2 TLBの高速化とあわせてこのあたりも改善すべきポイントではないかと思う。
