では実際にはどうか? ということで、まずは命令TLB廻りである。グラフ26～31は、Near/Far JumpをForward/Backward/Randomで行う際のLatencyを測定したもので、TLBから直ちに目的のアドレスを引っ張れれば少ないLatencyでアクセスできるし、TLBをミスしてキャッシュあるいはメモリからPTEを読み出すとLatencyが大きくなるという訳だ。

さて、結果を見ると「あれ?」という気分にならざるを得ない。どのケースでも、最小レイテンシは2cycleといったところ。L1 TLBは4KB PageだとCore MAもNehalem MAも同じスペックであり、実際データをみると35エントリあたりまではほぼ同等というか、むしろ高速である。

グラフ32は、グラフ26の先頭128エントリ分のみを抜き出した結果であるが、35エントリ付近まではCore MAよりもむしろ高速である。ところがこれを過ぎて64エントリ近くまでは、倍とは言わないが、Core MAの3cycleに対して5cycleと大幅にLatencyが増えていることがわかる。Core MAの場合4way assosiativeだから、最初の32entryは高速だが、その後は(一発でHitしないと)多少余分にLatencyが増えるのは当然だが、Nehalem MAの増え方は単なるassosiativeでは無い様に感じられる。

そこで確認のため、RMMAのI-TLB Associativityを見てみた。テストはNear JumpのForwardに限り、16/32/64/128 Entriesにおける数値を比較することにした。グラフ33がCore MAの、グラフ34がNehalem MA(HT有効)の結果である。

まず比較用のグラフ33であるが、4way Assosiativeであることが明確に判る結果になっている。Segment Countが4まではLatencyが低いが、そこからは余分に時間がかかり、Segment Countが8を超えるとTLBが溢れてキャッシュアクセスになる、ということが明確に判る。ではNehalem MAは? というと、確かにway数は4っぽいのだが、そこからのLatencyの増え方がかなり妙である。可能性としてあるのは、L2 TLBの存在であろう。こちらは4way AssosiativityのUnified TLBであるが、仮にL1 TLBで最初にHitしなかった場合、次のエントリを舐めるのと同時にL2 TLBのアクセスに行ったとすれば、こんな妙なグラフになっても不思議ではないように思える。

こうなると、エントリが増えたはいいが、むしろ性能面ではペナルティになりかねないところではある。ただ、これは「何をとるか」のバランスでもある。ちょっとグラフが戻るが、グラフ26～28を見る限り、Nehalem MAのTLBはいい事なしに思える。が、グラフ29～31、つまりFar Jumpの場合では、概ね270エントリあたりでNehalem MAはCore MAよりも効率が良くなる。要するにCore MAはTLBがフルになり、TLB Missが発生するケースでもまだCore MAは踏ん張れるという話であるが、こうした大規模なプログラムの性能向上を目指したのであれば、Nehalem MAのTLBは効果的と言える。逆に言えば、こうした大規模プログラムに向けた最適化が施された、というのが命令TLBに対する評価となるだろう。