# アウトオブオーダー実行(OOO) プロセッサがプログラムに書かれた命令順ではなく、**依存関係を満たせる命令から動的に実行**する手法。長レイテンシ命令(乗算・除算・メモリロード)の待機中にバブルを減らし、機能ユニットの稼働率を高める。 ## 仕組み 1. **デコード**: 命令を内部表現(μops)に変換。 2. **レジスタリネーミング**: アーキテクチャレジスタを物理レジスタに動的マッピングし、書き込み後に使われるレジスタの偽依存(WAR・WAW ハザード)を解消。 3. **発行キュー(リザベーションステーション)**: オペランドが揃った命令から機能ユニットへ発行(プログラム順でなくてよい)。 4. **リオーダーバッファ(ROB)**: 実行は順不同でも、**コミット(ライトバック)はプログラム順**に行い、例外や分岐誤予測時の正確なロールバックを保証。 ## レジスタリネーミングの意義 x86 は 32-bit モードで汎用レジスタ 8 本、64-bit モードで 16 本しかなく、これが依存関係の主因になる。OOO プロセッサは内部的に数十〜数百本の物理レジスタを持ち、動的マッピングで見かけの依存を除去する。RISC では恩恵はより小さい(元々レジスタが多い)。 ## x86 の μops 変換(「RISCy x86」) NexGen と Intel が独立に発明した手法。x86 命令をデコード時に RISC ライクな**μops(マイクロオペレーション)**へ変換し、OOO スーパースカラーコアで実行する。 - ほとんどの x86 命令は 1〜3 μops に変換。複雑な命令はそれ以上。 - Pentium Pro(P6)と NexGen Nx586 が最初の実装。 - 現代 x86 は**L0 μop キャッシュ**を持ち、デコードをスキップしてループを高速実行(Sandy Bridge〜)。L0 ヒット時のパイプライン段数が短くなる理由(Sandy Bridge: 14 vs 19 段)。 - AMD の Zen 系、Intel の Core 系すべてがこの方式。 ## OOO の効果と限界 OOO 実行のインオーダーに対する実際の性能向上は**約 20〜40%** 程度にとどまる。Andy Glew(Pentium Pro 主任設計者)の言葉: > "The dirty little secret of OOO is that we are often not very much OOO at all" 理由: キャッシュミスや分岐誤予測はリオーダーバッファに収まる命令数(数百)の範囲を超えると隠しきれない。コンパイラ最適化の恩恵も OOO 上では限定的。 ## コスト - ディスパッチロジックの複雑さと電力消費: OOO ロジックは常時動作するためトランジスタの「静的電力」的コストが大きい。 - チップ面積: リオーダーバッファ・リネームテーブル・発行キュー。 - 設計複雑度: 何年もの設計工数。 このコスト対効果のトレードオフが「Brainiac vs スピードデーモン」論争の核心。→ [[Brainiac設計]] ## インオーダー設計との比較 低消費電力プロセッサ(Cortex-A53、初期 Atom)は OOO を省くことで消費電力を大幅に削減。コンパイラの静的スケジューリングで補う。詳細 → [[VLIW]] ## 歴史 - MIPS R10000、Alpha 21264: 初期の代表的 OOO プロセッサ - POWER/PowerPC: リザベーションステーション(機能ユニット間 OOO)を持つが、ユニット内はインオーダー - Pentium Pro(1995): 消費者向け x86 への OOO 導入 - UltraSPARC III/IV、POWER6、Denver: 大型 OOO を意図的に省いたインオーダー設計(速度 or 電力を優先) ## 横断的知見 - 今後の取り込みで、複数ソース間の関係を追記する。 ## 未解決の問い - この概念をどのソース群で継続的に検証するか。