6

一方で、ウィキペディアはアウトオブオーダー実行の手順について次のように書いています。

  1. 命令フェッチ。
  2. 命令キュー (命令バッファーまたはリザベーション ステーションとも呼ばれます) への命令ディスパッチ。
  3. 命令は、その入力オペランドが使用可能になるまでキューで待機します。その後、命令は、以前の古い命令の前にキューを離れることを許可されます。
  4. 命令は適切な機能ユニットに発行され、そのユニットによって実行されます。
  5. 結果はキューに入れられます。
  6. すべての古い命令の結果がレジスタ ファイルに書き戻された後でのみ、この結果がレジスタ ファイルに書き戻されます。これは、卒業または退職段階と呼ばれます。

同様の情報は、「Computer Organization and Design」の本にも記載されています。

プログラムを単純な順序どおりのパイプラインで実行しているかのように動作させるには、命令フェッチおよびデコード ユニットが命令を順番に発行する必要があり、依存関係を追跡できるようにし、コミット ユニットが結果をレジスタに書き込み、プログラムフェッチ順序のメモリ。この保守的なモードは in-order commit と呼ばれます... 現在、動的にスケジュールされたパイプラインはすべてin-order commit を使用しています。

したがって、私が理解している限り、命令の実行が順不同で行われたとしても、それらの実行の結果はリオーダーバッファに保存され、決定論的な順序でメモリ/レジスタにコミットされます。

一方で、最近の CPU はパフォーマンスの高速化のためにメモリ操作を並べ替えることができるという既知の事実があります (たとえば、2 つの隣接する独立したロード命令を並べ替えることができます)。ウィキペディアはそれについてここに書いています。

この不一致を明らかにしていただけますか？

4

1 に答える 1

8

TL:DR: メモリの順序付けは、順不同の実行と同じではありません。これは、順番にパイプライン化された CPU でも発生します。

インオーダーコミットは、失敗した命令に正確にロールバックできる正確な例外のために必要であり、その後の命令はすでにリタイアされていません。アウト オブ オーダー実行の基本ルールは、シングル スレッド コードを壊さないことです。他の種類のメカニズムを使用せずに順不同のコミット (リタイア) を許可した場合、後の命令がすでに一度実行されているか、以前の命令がまだ実行されていない間に、ページ フォールトが発生する可能性があります。これにより、通常の方法ではページ フォールトを処理した後に実行を再開できなくなります。

(順序どおりの発行/名前変更および依存関係の追跡により、例外がない通常のケースで正しい実行が処理されます。)

メモリの順序付けは、他のコアが見るものに関するものです。また、引用したのは、結果をメモリではなくレジスタファイルにコミットすることについてのみ話していることに注意してください。

(脚注 1 :キロ命令プロセッサ: メモリの壁の克服は、チェックポイント状態に関する理論的な論文であり、例外の前のある時点で一貫したマシン状態にロールバックできるようにすることで、巨大な ROB なしではるかに大きなアウトオブオーダー ウィンドウを可能にします。私の知る限り、それを使用した主流の商用設計はありませんが、理論的には、使用可能な CPU を構築するための厳密な順序での廃止以外のアプローチがあることを示しています。

Apple の M1 は、同時代の x86 に比べて非常に大きなアウト オブ オーダー ウィンドウを持っていると伝えられていますが、非常に大きな ROB 以外のものを使用しているという明確な情報は見たことがありません。)

各コアのプライベート L1 キャッシュは、システム内の他のすべてのデータ キャッシュと一貫性があるため、メモリの順序付けは、命令がキャッシュをいつ読み書きするかの問題です。これは、故障したコアからリタイアするときとは別です。

キャッシュからデータを読み取ると、ロードがグローバルに表示されます。これは多かれ少なかれ「実行」されたときであり、リタイアする (つまりコミットする) かなり前のことです。

データがキャッシュにコミットされると、ストアはグローバルに表示されます。これは、それらが非投機的であることがわかるまで、つまり、ストアを「元に戻す」必要があるロールバックが例外や割り込みによって引き起こされないことがわかるまで待たなければなりません。そのため、ストアは、アウト オブ オーダー コアからリタイアした時点で、L1 キャッシュにコミットできます。

ただし、インオーダー CPU でさえ、ストア キューまたはストア バッファを使用して、L1 キャッシュでミスしたストアのレイテンシを隠します。ストアが確実に発生することがわかっている場合、アウトオブオーダー機構はストアを追跡し続ける必要がないため、ストア insn/uop は、L1 キャッシュにコミットする前であってもリタイアできます。ストア バッファは、L1 キャッシュがそれを受け入れる準備が整うまで保持されます。つまり、キャッシュ ラインを所有している場合 ( MESI キャッシュ コヒーレンシ プロトコルの排他的または変更済み状態)、メモリ順序付けルールにより、ストアがグローバルに表示されるようになります。

書き込みキャッシュ ポリシーの書き込み割り当て/フェッチに関する私の回答も参照してください。

私が理解しているように、ストアのデータは、アウトオブオーダーコアで「実行」されるとストアキューに追加され、それがストア実行ユニットの機能です。(アドレスを書き込む store-address と、割り当て/名前変更時に予約されている store-buffer エントリにデータを書き込む store-data により、これらの部分のいずれかが、Intel. )

ロードは、最近保存されたデータを確認できるように、ストア キューをプローブする必要があります。

x86 のような強力な順序付けを持つ ISA の場合、ストア キューは ISA のメモリ順序付けセマンティクスを保持する必要があります。つまり、ストアは他のストアと一緒に並べ替えることができず、以前のロードの前にストアをグローバルに表示することはできません。( LoadStore の並べ替えは許可されません (StoreStore または LoadLoad も許可されません)。StoreLoad の並べ替えのみ)。

Haswell とは異なる方法で TSX (トランザクション メモリ) を実装する方法に関するDavid Kanter の記事では、Memory Order Buffer についての洞察と、それが命令/uop の並べ替えを追跡する ReOrder Buffer (ROB) とは別の構造である方法について説明しています。彼は、グループとしてコミットまたはアボートできるトランザクションを追跡するためにどのように変更できるかを説明する前に、現在の仕組みを説明することから始めます。

于 2016-09-23T22:22:25.480 に答える