トップ «前の日記(2008-04-09) 最新 次の日記(2008-04-24)» 編集

U-memo

2006|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|08|
2009|08|10|
2010|02|03|
2011|11|12|
2012|04|
2016|02|
All= / Today= / Yesterday=

2008-04-22 [長年日記]

_ [プロセッサ] Nehalem の LSD はバッファかトレースキャッシュか

当サイト的な分析であるが、大原先生の言うとおりこのバッファが質的には事実上のトレースキャッシュである点は間違いないだろう。 理由は簡単で、同記事にもあるとおり単なるバッファならFIFOバッファであるべきところをファーストループに沿って再実行できる点と、x86ではなくμOPsを保存することでデコードを省略している点から読み取る事ができる。トレースキャッシュの本質は「デコードと実行をデカップルすること」にあるわけだから、LSDはその条件を満たしている。 (Core MAの構造ではデコードと実行をデカップルできないから、一見似ているが動作の本質は全く異なる。)

このバッファは決してトレースキャッシュではない。分岐予測に失敗した場合には何処から再起動が掛かるかを考えると、トレースキャッシュとの違いが鮮明になる。 分岐予測に失敗した場合にもトレースキャッシュにHitする限りデコードをすっとばせるが、LSD および命令バッファは分岐予測ミスしたら flush されてしまって、デコードをすっ飛ばすことは不可能(のはず)。

つまりトレースキャッシュは実行パイプラインの(レイテンシの)短縮化が主な目的になっているのだが、命令バッファはあくまでも命令キャッシュ(メモリ)と実行部とのデカップルが目的(=メモリレイテンシの隠蔽と実効スループットの確保)である。

トレースキャッシュはその存在により、Hit すれば命令実行パイプラインが短いが、現実には Miss する割合がそれなりに避けられない以上、Hit/Miss の混在によって L1I$ 〜実行部への直接パスのスループットを阻害しうる (トレースキャッシュへの書き込み処理などが邪魔する) 。つまりスループット変動を起こしやすく、実効スループットは低下しやすい。

逆に、命令バッファは L1I$ 〜実行部の「実効」スループットを確保することが本質的な目的であり、パイプラインの全長は短くならない(しない)。

そう考えると、CoreMA方式とNehalem方式ではこのLSDを含むバッファの「目的」の点では差が無い。デコードの前段か後段かの違いがあるだけであり、「命令キャッシュ(メモリ)との」デカップルという目的はどちらも達成している。

ただし、x86アーキテクチャはデコードスループットが致命的なボトルネックになりやすい (あんな変態的な命令体系でスーパースカラは大変)ので、デコーダの後ろでデカップルするというのは、実効スループットを稼ぐという命令バッファの目的に最も適っている。つまり命令バッファをx86アーキテクチャ向けに最適化したというスループット向上の正当進化であって、レイテンシ主眼スループット無視(...は言い過ぎか)のトレースキャッシュのような先祖返りでは無いのである。

LSD もこの「実効スループット確保」の目的を考えると自然である。 前回の日記でも書いたことだが、ショートループになる場合には命令キャッシュ〜分岐予測機構の実効供給能力がピークの半分以下に下がる。 ループになる分岐命令は高い精度で分岐予測が出来るのに勿体ない話であって、ILP を確保できる優良顧客からしっかり確保しようというのが LSD である。

トレースキャッシュもショートループはキャッシュヒットするから高い性能が出るわけで、ショートループだけに目を付ければ同じように高スループットの挙動を観測できるので、同一視したくなるのは仕方がない話ですが。