ランアヘッド

ランアヘッドは、コンピュータプロセッサがキャッシュミスサイクル中に命令を投機的に前処理できるようにする技術です。前処理された命令は、キャッシュミス（通常、長いレイテンシのロードと呼ばれる）につながる命令を通常よりも早く実行することで命令とデータストリームのプリフェッチを生成するために使用され、メモリレイテンシを効果的に隠します。ランアヘッドでは、プロセッサはアイドル実行リソースを使用して、キャッシュミスとは無関係な利用可能な情報を使用して命令とデータストリームのアドレスを計算します。プロセッサが最初のキャッシュミスを解決すると、すべてのランアヘッドの結果は破棄され、プロセッサは通常どおり実行を再開します。この技術の主な使用例は、メモリウォールの影響を軽減することです。この技術は、分岐結果を事前計算して高精度の分岐予測を実現するなど、他の目的にも使用できます。^[1]

主なハードウェアコストは、レジスタファイルの状態をチェックポイントする手段です。通常、ランアヘッドプロセッサには小さな追加キャッシュも含まれており、これにより、ランアヘッドストア操作を実際のメモリを変更することなく実行できます。特定の実装では、専用のハードウェアアクセラレーションユニットを使用して、事前処理された命令の特定のスライスを実行します。^[2]^[3]

ランアヘッドは当初、インオーダーマイクロプロセッサのコンテキストで研究されましたが、^{[4]この手法は}アウトオブオーダーマイクロプロセッサでも使用できるように拡張されました。^[5]

トリガー

原理的には、どのようなイベントでもランアヘッドをトリガーできますが、通常、エントリ条件は、リオーダーバッファの先頭に到達する最後のレベルのデータキャッシュミスです。^[5]通常のアウトオブオーダープロセッサでは、このような長いレイテンシのロード命令は、ミスが処理されてロードがリタイアされるまで、すべての若い命令のリタイアをブロックします。

プロセッサがランアヘッドモードに入ると、すべてのアーキテクチャレジスタのチェックポイントが取られ、ランアヘッドモードに入る原因となったロード命令のアドレスが記録されます。パイプライン内のすべての命令は、ランアヘッドとしてマークされます。キャッシュミスから返される値は事前に知ることができないため、前処理された命令が不明または無効なデータに依存する可能性があります。このようなデータを含むレジスタ、またはそれに依存するデータは、レジスタファイル内のすべてのレジスタに「無効」または INV ビットを追加することによって示されます。このような無効なデータを使用または書き込む命令も、INV ビットでマークされます。ランアヘッドを開始した命令がロードである場合、偽の結果が発行され、INV としてマークされるため、宛先レジスタを INV としてマークしてパイプラインからドレインできます。

前処理手順

ランアヘッドモードでは、プロセッサはランアヘッドを開始した命令の後の命令の実行を継続します。ただし、ランアヘッドは投機的な状態と見なされ、プロセッサは追加のデータと命令キャッシュミス (実質的にはプリフェッチ) の生成のみを試みます。設計者は、失われた命令の影響が不明であるため、生成されるプリフェッチの品質が低下することを理解した上で、ランアヘッドが命令キャッシュに存在しない命令をスキップできるように選択できます。

INV とマークされた 1 つ以上のソースレジスタを持つ命令のターゲットレジスタは、INV とマークされます。これにより、プロセッサは、ランアヘッドモード中にどのレジスタ値が (おそらく) 信頼できるかを知ることができます。INV ソースレジスタが原因で解決できない分岐命令は、単に正しく予測されたと想定されます。分岐が誤って予測された場合、プロセッサは分岐に依存しないポイントに到達するまで間違ったパスの命令を実行し続けます。これにより、キャッシュを無駄なデータエントリで汚染する間違ったパスのロードが実行される場合があります。有効な分岐命令の結果は、通常の操作中に非常に正確な予測として後で使用するために保存できます。

ランアヘッドは投機的な状態なので、ストア命令でメモリを変更することはできません。ストアの結果を依存するロードに伝えるために、ランアヘッドロードとミスによってのみアクセスされる、ランアヘッドキャッシュと呼ばれる非常に小さなキャッシュを使用できます。^[5]このキャッシュは機能的には通常のキャッシュに似ていますが、無効なデータを追跡するための INV ビットが含まれています。INV ストアは対応するターゲットキャッシュラインの INV ビットを設定し、有効なストアはキャッシュラインの INV ビットをリセットします。ランアヘッドロード命令は、実キャッシュとランアヘッドキャッシュの両方をチェックする必要があります。ロードがランアヘッドキャッシュでヒットした場合、実キャッシュの結果を破棄してランアヘッドキャッシュデータを使用します。キャッシュラインが INV ビットでマークされていた場合は無効になる可能性があります。ランアヘッドキャッシュはメモリ階層から分離されているため、古いデータを追い出す場所はありません。したがって、キャッシュが競合した場合、古いデータは単にキャッシュから削除されます。ランアヘッドキャッシュのサイズが限られているため、ランアヘッドモード中に INV データを完全に追跡することはできません (キャッシュ競合で INV データが有効なデータによって上書きされる可能性があるため)。実際には、ランアヘッドモード中に計算された結果はすべて破棄されるため、これは重要ではありません。

終了

ランアヘッドに入る場合と同様に、原則として、あらゆるイベントがランアヘッドを終了する原因となります。ただし、キャッシュミスによって開始されたランアヘッド期間の場合、通常はキャッシュミスが処理されると終了します。

プロセッサがランアヘッドを終了すると、ランアヘッドを開始した命令を含む、それより新しいすべての命令が圧縮され、パイプラインから排出されます。その後、アーキテクチャレジスタファイルはチェックポイントから復元されます。次に、事前に決定されたレジスタエイリアシングテーブル(RAT) がフロントエンドとバックエンドの両方の RAT にコピーされます。最後に、プロセッサはランアヘッドを開始した命令のアドレスにリダイレクトされます。その後、プロセッサは通常モードで実行を再開します。

レジスタファイルチェックポイントオプション

アーキテクチャレジスタファイル (ARF) をチェックポイント化する最も簡単な方法は、プロセッサがランアヘッドモードに入ったときに、物理レジスタファイル(PRF) 全体 (PRF は ARF のスーパーセットであるため) の完全なコピーをチェックポイントレジスタファイル (CRF) に実行することです。ランアヘッドモードが終了すると、プロセッサは CRF から PRF への完全なコピーを実行できます。ただし、より効率的なオプションも利用できます。

コピー操作をなくす 1 つの方法は、通常の操作中に PRF と CRF の両方に書き込むことですが、runahead モードでは PRF にのみ書き込みます。このアプローチでは、CRF と PRF に並行して書き込む場合に runahead の開始時に発生するチェックポイントのオーバーヘッドを排除できますが、runahead が終了したときにプロセッサが PRF を復元する必要があります。

チェックポイントを設定する必要があるレジスタはアーキテクチャレジスタのみであるため、CRF には、命令セットアーキテクチャで定義されているアーキテクチャレジスタと同じ数のレジスタのみを含める必要があります。プロセッサには通常、アーキテクチャレジスタよりもはるかに多くの物理レジスタが含まれているため、CRF のサイズが大幅に縮小されます。

さらに積極的なアプローチは、マイクロアーキテクチャのオペランド転送パスのみに依存して、runahead モード中に変更された値を提供することです。 ^{[引用が必要]}次に、runahead 中にレジスタファイルへの書き込みを無効にすることで、レジスタファイルに「チェックポイント」が設定されます。

最適化

ランアヘッドはプロセッサのパフォーマンスを向上させることを目的としていますが、プロセッサがアイドル状態のときに命令を前処理すると、動的電力消費が増加するため、プロセッサのエネルギー効率が低下します。さらに、ランアヘッドの開始と終了は、レジスタチェックポイントと特にパイプラインのフラッシュが完了するまでに多くのサイクルを要する可能性があるため、パフォーマンスオーバーヘッドが発生します。したがって、あらゆる機会にランアヘッドを開始するのは賢明ではありません。

runahead のエネルギー効率を向上させる最適化には次のようなものがあります。

プロセッサがランナヘッド中に長いレイテンシのロードを実行することが予想される場合にのみランナヘッドに入り、それによって短く非生産的なランナヘッド期間を削減します。^[6]
ランアヘッド期間の長さを、有用な結果を生み出すと予想される期間のみに制限する。^[7]
最終的にロード命令につながる前処理命令のみ。^[8]
空いているプロセッサリソースのみを使用して命令を前処理します。^[9]
ランアヘッド中にデコードされたマイクロ操作をバッファリングし、通常モードで再利用する。^[9]

副作用

ランアヘッドは、副作用としてプロセッサのソフトエラー率を改善することがわかっています。プロセッサがキャッシュミスを待っている間、キャッシュミスが未解決の間、プロセッサの状態全体がソフトエラーに対して脆弱です。ランアヘッドは実行を継続することで、プロセッサの状態がソフトエラーに対して脆弱な時間を意図せずに短縮し、それによってソフトエラー率を低下させます。^[10]

参照

参考文献

^ Pruett, Stephen; Patt, Yale (2021 年 10 月)。「Branch Runahead: 予測不可能な分岐に対する分岐予測の代替手段」。MICRO -54: 第 54 回 IEEE/ACM国際マイクロアーキテクチャシンポジウム。MICRO '21。ニューヨーク、ニューヨーク州、米国: Association for Computing Machinery。pp. 804–815。doi :10.1145/ 3466752.3480053。ISBN 978-1-4503-8557-2. S2CID 239011545。
^ Hashemi, Milad; Mutlu, Onur ; Patt, Yale N. (2016 年 10 月)。「Continuous runahead: メモリ集約型ワークロード向けの透過的なハードウェアアクセラレーション」。2016年 49 回 IEEE/ACM 国際マイクロアーキテクチャシンポジウム (MICRO)。pp. 1–12。doi :10.1109/ MICRO.2016.7783764。ISBN 978-1-5090-3508-3. S2CID 439575。
^ Pruett, Stephen; Patt, Yale (2021 年 10 月)。「Branch Runahead: 予測不可能な分岐に対する分岐予測の代替手段」。MICRO -54: 第 54 回 IEEE/ACM国際マイクロアーキテクチャシンポジウム。MICRO '21。ニューヨーク、ニューヨーク州、米国: Association for Computing Machinery。pp. 804–815。doi :10.1145/ 3466752.3480053。ISBN 978-1-4503-8557-2. S2CID 239011545。
^ Dundas, James D. および Mudge, Trevor N. (1996 年 9 月)。「ストールサイクルを使用したマイクロプロセッサのパフォーマンスの向上」。技術レポート。ミシガン大学電気工学およびコンピュータサイエンス学部。
^ abc Mutlu, O.; Stark, J.; Wilkerson, C.; Patt, YN (2003 年 2 月)。「Runahead 実行: アウトオブオーダープロセッサ用の非常に大きな命令ウィンドウの代替手段」。第9回高性能コンピュータアーキテクチャ国際シンポジウム、2003 年。HPCA-9 2003。議事録。pp . 129–140。doi :10.1109/HPCA.2003.1183532。ISBN 0-7695-1871-0. S2CID 9016814。
^ ヴァン・クレイネスト、ケンゾー;アイルマン、スタイン。 Eeckhout、Lieven (2009)、Seznec、André;エマー、ジョエル。オボイル、マイケル。 Martonosi、Margaret (編)、「同時マルチスレッドプロセッサにおける MLP-Aware Runahead Threads」、High Performance Embedded Architectures and Compilers、vol. 5409、ベルリン、ハイデルベルク: Springer Berlin Heidelberg、pp. 110–124、doi :10.1007/978-3-540-92990-1_10、ISBN 978-3-540-92989-5、2023-06-02取得
^ ヴァン・クレイネスト、ケンゾー;アイルマン、スタイン。エックハウト、リーヴェン (2009)。「同時マルチスレッドプロセッサにおける MLP 対応の暴走スレッド」。アンドレのセズネツにて。エマー、ジョエル。オボイル、マイケル。マルトノシ、マーガレット。ウンゲラー、テオ (編)。高性能組み込みアーキテクチャとコンパイラ。コンピューターサイエンスの講義ノート。 Vol. 5409. ベルリン、ハイデルベルク：シュプリンガー。 110–124ページ。土井：10.1007/978-3-540-92990-1_10。ISBN 978-3-540-92990-1。
^ Hashemi, Milad; Patt, Yale N. (2015-12-05). 「runahead バッファによるフィルタされた runahead 実行」。第48回国際マイクロアーキテクチャシンポジウム議事録。MICRO-48。ニューヨーク、ニューヨーク州、米国: Association for Computing Machinery。pp. 358–369。doi :10.1145/2830772.2830812。ISBN 978-1-4503-4034-2. S2CID 2897777。
^ ab ナイタニ、アジェヤ;フェリウ、ジョズエ。アディーレ、アルムタズ。リーフェン、エックハウト（2020年2月）。「正確な暴走処刑」。2020 年高性能コンピュータアーキテクチャ (HPCA) に関する IEEE 国際シンポジウム。 397–410ページ。土井：10.1109/HPCA47549.2020.00040。hdl :1854/LU-8668193。ISBN 978-1-7281-6149-5. S2CID 215817567。
^ Naithani, Ajeya; Eeckhout, Lieven (2022 年 4 月)。「信頼性を考慮した Runahead」。2022 IEEE 高性能コンピュータアーキテクチャ (HPCA) に関する国際シンポジウム。IEEE。pp . 772–785。doi : 10.1109 /HPCA53966.2022.00062。ISBN 978-1-6654-2027-3. S2CID 248865294。

[1] Pruett, Stephen; Patt, Yale (2021 年 10 月)。「Branch Runahead: 予測不可能な分岐に対する分岐予測の代替手段」。MICRO -54: 第 54 回 IEEE/ACM国際マイクロアーキテクチャシンポジウム。MICRO '21。ニューヨーク、ニューヨーク州、米国: Association for Computing Machinery。pp. 804–815。doi :10.1145/ 3466752.3480053。ISBN 978-1-4503-8557-2. S2CID 239011545。

[2] ^ Hashemi, Milad; Mutlu, Onur ; Patt, Yale N. (2016 年 10 月)。「Continuous runahead: メモリ集約型ワークロード向けの透過的なハードウェアアクセラレーション」。2016年 49 回 IEEE/ACM 国際マイクロアーキテクチャシンポジウム (MICRO)。pp. 1–12。doi :10.1109/ MICRO.2016.7783764。ISBN 978-1-5090-3508-3. S2CID 439575。

[3] Pruett, Stephen; Patt, Yale (2021 年 10 月)。「Branch Runahead: 予測不可能な分岐に対する分岐予測の代替手段」。MICRO -54: 第 54 回 IEEE/ACM国際マイクロアーキテクチャシンポジウム。MICRO '21。ニューヨーク、ニューヨーク州、米国: Association for Computing Machinery。pp. 804–815。doi :10.1145/ 3466752.3480053。ISBN 978-1-4503-8557-2. S2CID 239011545。

[4] Dundas, James D. および Mudge, Trevor N. (1996 年 9 月)。「ストールサイクルを使用したマイクロプロセッサのパフォーマンスの向上」。技術レポート。ミシガン大学電気工学およびコンピュータサイエンス学部。

[:0-5] Mutlu, O.; Stark, J.; Wilkerson, C.; Patt, YN (2003 年 2 月)。「Runahead 実行: アウトオブオーダープロセッサ用の非常に大きな命令ウィンドウの代替手段」。第9回高性能コンピュータアーキテクチャ国際シンポジウム、2003 年。HPCA-9 2003。議事録。pp . 129–140。doi :10.1109/HPCA.2003.1183532。ISBN 0-7695-1871-0. S2CID 9016814。

[6] ヴァン・クレイネスト、ケンゾー;アイルマン、スタイン。 Eeckhout、Lieven (2009)、Seznec、André;エマー、ジョエル。オボイル、マイケル。 Martonosi、Margaret (編)、「同時マルチスレッドプロセッサにおける MLP-Aware Runahead Threads」、High Performance Embedded Architectures and Compilers、vol. 5409、ベルリン、ハイデルベルク: Springer Berlin Heidelberg、pp. 110–124、doi :10.1007/978-3-540-92990-1_10、ISBN 978-3-540-92989-5、2023-06-02取得

[7] ヴァン・クレイネスト、ケンゾー;アイルマン、スタイン。エックハウト、リーヴェン (2009)。「同時マルチスレッドプロセッサにおける MLP 対応の暴走スレッド」。アンドレのセズネツにて。エマー、ジョエル。オボイル、マイケル。マルトノシ、マーガレット。ウンゲラー、テオ (編)。高性能組み込みアーキテクチャとコンパイラ。コンピューターサイエンスの講義ノート。 Vol. 5409. ベルリン、ハイデルベルク：シュプリンガー。 110–124ページ。土井：10.1007/978-3-540-92990-1_10。ISBN 978-3-540-92990-1。

[8] Hashemi, Milad; Patt, Yale N. (2015-12-05). 「runahead バッファによるフィルタされた runahead 実行」。第48回国際マイクロアーキテクチャシンポジウム議事録。MICRO-48。ニューヨーク、ニューヨーク州、米国: Association for Computing Machinery。pp. 358–369。doi :10.1145/2830772.2830812。ISBN 978-1-4503-4034-2. S2CID 2897777。

[:1-9] ナイタニ、アジェヤ;フェリウ、ジョズエ。アディーレ、アルムタズ。リーフェン、エックハウト（2020年2月）。「正確な暴走処刑」。2020 年高性能コンピュータアーキテクチャ (HPCA) に関する IEEE 国際シンポジウム。 397–410ページ。土井：10.1109/HPCA47549.2020.00040。hdl :1854/LU-8668193。ISBN 978-1-7281-6149-5. S2CID 215817567。

[10] Naithani, Ajeya; Eeckhout, Lieven (2022 年 4 月)。「信頼性を考慮した Runahead」。2022 IEEE 高性能コンピュータアーキテクチャ (HPCA) に関する国際シンポジウム。IEEE。pp . 772–785。doi : 10.1109 /HPCA53966.2022.00062。ISBN 978-1-6654-2027-3. S2CID 248865294。