ベクトルアーキテクチャに関して面白そうな論文があったので読んでみることにした：
https://ieeexplore.ieee.org/document/9651636
- Register Flush-free Runahead Execution for Modern Vector Processors
現代のベクトルプロセッサにおいて，ベクトル・ロード・ストア命令のレイテンシが大きいことにより，ベクトル算術演算命令とのレイテンシの差にギャップがある． これを解決するためには，より多くの資源を積んで投機的に実行するアウトオブオーダ実行が有効である． アウトオブオーダ実行により，各イタレーションの並列性を抽出したり，メモリレベル並列性を抽出することでより高速に動作することができるようになる．
本論文においては，命令レベルの並列性をさらに活用するランナヘッド実行を導入する． ランナヘッド実行というのは，キャッシュミスなどのハザードによりプロセッサの実行が止まってしまった場合でも，可能な限り実行できるものは実行するプロセッサの状態を言う． ランナヘッド実行はプリフェッチと異なり将来のメモリアクセスを予測するのではなく，メモリアドレスが計算可能なロード命令に関してはストール状態であってもメモリアクセスを行う． 予測ではなく確かなアドレス計算に基づくので確実に必要なブロックをロードすることができることが，プリフェッチに対する利点となる．
従来のランナヘッド実行は，プロセッサがストールしたことにより通常モードからランナヘッドモードに変更する． この方式だとランナヘッドモードで計算されたレジスタの値をランナヘッドモード終了後にフラッシュするため，そのレジスタの値を再利用できない（ここではベクトルレジスタの要素として1ベクトルレジスタが256要素を保持できるような，非常に長いベクトルレジスタを持っている状態を想定する） これによりコアとキャッシュの帯域を消費してしまう． これを解決するために通常モードに戻った後でもプロセッサがレジスタを使用できるように，ランナヘッドモードで結果を含むレジスタを残しておくことを提案する． この効果により，ランナヘッドモード終了後に，ランナヘッドモードで使用したレジスタを再利用，調停することによりオーバヘッドを削減する．
想定するプロセッサの構成は以下のとおりである：
次に，HPCアプリケーションの特徴についてまとめる：
- 同じ構造のループを何度も繰り返し，これは実行中に同じアドレスの命令（すなわちPC）が繰り返し現れる傾向があることを示している
- 1回のイタレーションで数百の命令を使用する．
- 図2は、ベクトル・プロセッサのアプリケーションにおける1回の繰り返しにおける命令数を示している。
- LandMineカーネル以外のアプリケーションは，1回のイタレーションで登場する命令が多く、アウトオブオーダーウィンドウが1回の繰り返しの命令で埋め尽くされやすい．
次に，ランナヘッド実行についてまとめる． プロセッサの命令ウィンドウがいっぱいになり発行が停止されると，ランナヘッドモードに移行する． プロセッサはランナヘッドモード実行中，将来アクセスが発生する命令をフェッチして実行する． これはプリフェッチに相当するが，学習などを行わず将来アクセスする命令のアドレスに基づいて発行するため，正確に必要なデータを取り込むことができる．
このとき，プロセッサはランナヘッドモードに入るときに，物理レジスタをバックアップ・スペースにコピーする． これはランナヘッドモードが解消されると復帰される．
一方で，ベクトル命令の場合はランナヘッドモード終了時に物理ベクトルを再ロードするコストは無視できない． ベクトルロード命令を再実行する必要があり，それによる性能オーバヘッドが発生する可能性があるからである．
以降続く
