インテルのTFLOPSチップはずいぶん奇妙なアーキテクチャだが、本質的にはSIMDだろう。
命令を4GHzで分配できっこないわな。
Augustus K. Uht and Vijay Sindagi:
Disjoint Eagar Execution: An Optimal Form of Speculative Execution
(MICRO28, 1995)
天才Uhtの最重要論文の一つ。
プロセッサ資源が余っていれば、その時点で未実行な基本ブロックのうち最も実行確率の高いものを投機実行する。
Toshinori Sato, Yusuke Nakamura, Itsujiro Arita:
Revisiting Direct Tag Search Algorithm on Superscalar Processors
(Workshop on Complexity-Effective Design, 2001)
CAMのかわりにRAMで構成した命令ウィンドウの話。
Dataflow Management Tableと命令キューの二つのRAMから構成されている。
DMTのほうは物理レジスタ番号でインデックスされ、その物理レジスタの値を使用する命令のidと左右フラグを保持する。データフローマシンの宛先フィールドと同じ。
DMTに記録されている命令のidは命令キューのインデックスになる。
命令キューには、左右オペランドそれぞれのreadyフラグ(とオペランドの値)を格納する。
命令が発行されると、命令キューのエントリを確保し、左右各オペランドについて、
対応するDMTにそのエントリ番号(=id)と左右フラグを書き込む。
オペランドが到着すると、DMTの対応するフィールドからidと左右フラグを読みだし、
idに対応する命令キューのreadyフラグをセットする。
左右ともreadyになった命令が実行可能となる。
DMTのidフィールドがすでに埋まっている場合の方針は
1.命令発行を停止。
2.命令キューに入れる。命令キューの先頭に来たら命令発行。
3.命令キューに入れる。スコアボードを用いてactiveにオペランドのチェックをする。(Advanced EDF instruction window)
とある。
1.については、idフィールドが3つあれば十分。
2.はまったくふるわない。
3.はidフィールドが1エントリでもさほど性能低下はしない。
オペランド到着からwakeupまで、DMTと命令キューの2段のRAM lookupが必要なのはいかがなものか。
Advanced EDF instruction windowについても、エントリ数によってはそれなりに複雑になると思う。
Alvin R. Lebeck, Jinson Koppanalil, Tong Li, Jaidev Patwardhan, and Eric Rotenberg:
A Large, Fast Instruction Window for Tolerating Cache Misses
(ISCA'02)
キャッシュミスしたロード命令に依存する命令を命令ウィンドウから取り除いて別のバッファ(=Waiting Instruction Buffer)に入れたり出したりする話。
ロード命令がキャッシュミスすると、pretend readyというモードになって、普通にreadyな命令と同じようにissueされる。但し行き先は実行ユニットではなくWIB。
キャッシュミスしたロード命令それぞれに対してワイヤが割当てられていて、WIBの各エントリがそのloadに(直接あるいは間接的に)依存しているか否かを示すビットを持っている。
複数オペランドのマッチングをしないことをのぞけば五島式直接依存行列と同じ。
WIB中の実行可能になった命令は命令ウィンドウに戻される。
WIBではオペランドのマッチングをしないため、WIBから命令ウィンドウに戻された命令であっても、他方のオペランドがやはりキャッシュミスした命令に依存していることがある。その場合は再びWIB行きとなる。
分岐予測ミス時にWIBエントリのパージをする必要があるので、WIBはROBといっしょにインオーダーに割当てられる。
32エントリ命令ウィンドウ+2k WIB/ROBの性能は、32 IQ/2k ROBと2k IQ/2k ROBの中間くらい。
Steven E. Raasch, Nathan L. Binkert, and Steven K. Reinhardt:
A Scalable Instruction Queue Design Using Dependence Chains
(ISCA'02)
32エントリ程度の命令ウィンドウを何段かカスケードして大きな命令ウィンドウを構成する話。
Dependence chainの中での位置によって、どの命令ウィンドウに入れるかが決まる。
Dependence chainとは、レイテンシの不明な命令をheadとし、それに直接あるいは間接的に依存する命令が連なったもの。
2入力命令でかつ両方のオペランドが未到着の場合は、それ自身が新たなchain headとなるか、後から到着するほうのオペランドを予測して、そちらのchainに入れる。
Chain headがissueされると後続の命令はself-timed modeになり、wakeupされるのを待たずに自分でばりばり命令ウィンドウを前進するようになる。
性能は、chainの数にもよるが同じサイズの普通の命令ウィンドウの80%くらい。
レイテンシ予測ミスに強いdataflow preschedulingといった感じだが、複雑なわりにはいまいち。(著者はクリティカルパスは短いと主張しているが)
WIB方式のほうがよさそう。
Ramon Canal and Antonio Gonza'les:
Reducing the Complexity of the Issue Logic
(ICS'01)
ICS2000の論文のマイナーチェンジ。
Ramon Canal and Antonio Gonza'les:
A Low-Complexity Issue Logic
(ICS2000)
一つ目は物理レジスタ番号でインデックスされるテーブルに、後続の命令を格納するという話。
命令ウィンドウがCAMではなくRAMなところがウリ。
未到着なオペランドが0個の場合は、レディキュー行き。
1個の場合は、そのオペランドのレジスタ番号に対応するエントリに挿入。
2個の場合は、それぞれのオペランドのレジスタ番号に対応するエントリに挿入して、互いにポインタで指す。
オペランド到着時に対応するエントリのポインタがnullだと命令をwakeupする。
ポインタが有効な場合は、指す先のエントリのポインタフィールドをクリアすることによって、マッチングを行う。
エントリがすでに埋まっていた場合にはストールするか、補助バッファ(FIFOまたはCAMの命令ウィンドウ)行き。
前二者は性能は全くふるわない。
後者については、64エントリのRAM+16エントリのCAMで、従来方式の64エントリのCAMとほぼ同じ性能。
二つ目はdataflow preschedulingだが、Michaudのと違ってレイテンシがわからない命令はそれ用のバッファ(CAM)に入れておくようになっている。
こちらも64エントリのRAM+16エントリのCAMで従来方式の64エントリのCAMとほぼ同じ性能。
Low-complexityと言っているが、でかいCAMよりはマシとはいえ、オペランドのマッチングに2段階の
テーブル参照が必要なのでだめだと思う。ポート数も増えるし、左右のオペランドが
同時に到着したらどうすんのよ。
Pierre Michaud and Andre' Seznec:
Data-Flow Prescheduling for Large Instruction Windows in Out-of-Order Processors
(HPCA'01)
命令の依存関係からデータフローグラフを実行時に構成して、likely readyな命令だけを従来方式の命令ウィンドウに挿入するという話。
命令ウィンドウサイズは性能にほとんど影響しないので、大きなウィンドウ(>32エントリ)になると従来方式に逆転されている。
性能が上らないのはロード命令のレイテンシ予測が外れた時の影響がでかいからだろう。
またハードウェアもかなり複雑なので、ぶっちゃけ
だ め ぽ
Recent Comments