ISCA 2024で発表された「Constable: Improving Performance and Power Efficiency by Safely Eliminating Load Instruction Execution」という論文を読んでみることにする。

どうやら Best Paper Awardはこの論文がとったらしい。

Congratulations to @write2bera & co-authors on receiving the Best Paper Award @ISCAConfOrg for "Constable: Improving Performance and Power Efficiency by Safely Eliminating Load Instruction Execution"https://t.co/e0BZS0eDDc https://t.co/4bgh5kDptJ @_onurmutlu_ @konkanello @intel pic.twitter.com/RziNbk8BbZ
— SAFARI Research Group (@SAFARI_ETH_CMU) 2024年7月3日

イントロダクションからまとめていく。時間が無いので少しずつ。

msyksphinz.hatenablog.com

4. Performance Headroom of Constable

ロード命令の実行を排除することで得られる性能向上の可能性を評価するために、まずは実際のワークロードで繰り返し同じデータを同じアドレスから取得する「グローバル安定ロード命令」を特定する。これらの命令は、アドレス計算とデータ取得の両方の操作が同じ結果をもたらすため、実行を排除するのに適している。

グローバル安定ロード命令の存在

多くの実際のワークロードでは、コンパイラの最適化を経てもなお、グローバル安定ロード命令が存在することがわかる。図3(a)に示すように、平均で34.2%のロード命令がグローバル安定であり、特にクライアント、エンタープライズ、サーバーワークロードではその割合が高い。また、図3(b)ではグローバル安定ロード命令が様々なアドレッシングモードを使用していることが示されている。例えば、PC-relative、スタック-relative、レジスタ-relativeの各アドレッシングモードが存在する。図3(c)はこれらの命令の出現間隔を示しており、50命令以内に再出現するものと250命令以上離れて再出現するものがあることがわかる。

リソース依存の分析

グローバル安定ロード命令は、リソース依存を引き起こし、命令レベルの並列性（ILP）を制限している。図6(a)に示すように、ロードポートの利用状況を分析すると、総実行サイクルの平均32.7%で少なくとも1つのロードポートが使用されていることがわかる。図6(b)によると、このうち23.0%のサイクルでは、グローバル安定ロード命令がロードポートを使用し、他のロード命令が待機している。このため、グローバル安定ロード命令を排除することで、リソースの競合が減少し、性能が向上する可能性がある。

性能向上の可能性

グローバル安定ロード命令の実行を排除することで、理想的な条件下では最大9.1%の性能向上が見込まれる。図7に示すように、これは理想的なロード値予測（Ideal Stable LVP）やデータフェッチの排除を伴うロード値予測（Ideal Stable LVP + data fetch elimination）よりも高い性能向上を示している。また、2倍のロード実行幅を持つプロセッサ構成と比較しても、Constableはわずかに優れた性能向上を示す。

これを実現するために、Constableは以下の方法を採用する：

グローバル安定ロード命令を動的に特定し、信頼性が高い場合はその実行を排除する。
ソースレジスタやメモリアドレスが変更された場合にのみ、ロード命令の実行を再度許可する。

これにより、ロード命令のデータ依存とリソース依存の両方を軽減し、プロセッサの性能を大幅に向上させることができる。

5. Constable: Key Insight

Constableの基本的な洞察は、あるロード命令が繰り返し同じメモリアドレスから同じ値を取得する場合、そのロード命令の実行を安全に排除できるという点にある。この洞察を元に、Constableは2つの重要なステップで動作する。

ステップ1: 安定的ロード命令の特定

最初のステップでは、Constableは過去の実行結果を分析して、繰り返し同じ値を取得するロード命令を動的に特定する。これらのロード命令を「安定的ロード命令」と呼ぶ。

具体的なプロセス:

Stable Load Detector(SLD): プログラム・カウンタ（PC）をインデックスとするテーブルを使用して、各ロード命令の過去の実行結果を追跡する。SLDには、最後に計算されたロードアドレス、最後に取得された値、安定性信頼度レベル、および実行を排除できるかどうかを示すフラグが格納される。
信頼性の構築: 各ロード命令が実行されるたびに、SLDは現在のアドレスと値を以前のものと比較する。両者が一致すれば、安定性信頼度レベルを増加させ、一致しなければ信頼度を減少させる。信頼度が一定の閾値を超えた場合、そのロード命令を「安定的ロード命令」として特定する。

図8(a)に示すように、SLDはロード命令の過去の実行結果を基にして、その命令が安定的かどうかを判断し、その実行を排除できるかどうかを決定する。

ステップ2: ロード命令の実行排除

第二のステップでは、Constableが特定した安定的ロード命令の実行を排除する。

具体的なプロセス:

排除の条件: Constableは、SLDの”can_eliminate”フラグが設定されている場合にのみ、ロード命令の実行を排除する。このフラグが設定されると、ロード命令のアドレス計算およびデータ取得操作をスキップし、最後に取得した値を使用する。
データ依存の解消: ロード命令の実行を排除するためには、ロード命令のソースレジスタが前回の実行から変更されていないこと、およびロード命令がアクセスするメモリアドレスに対してストア命令やスヌープ要求が発生していないことが必要である。
監視と更新: Register Monitor Table（RMT）とAddress Monitor Table（AMT）は、ソースレジスタやメモリアドレスの変更を監視し、必要に応じてSLDの”can_eliminate”フラグをリセットする。これにより、変更があった場合にロード命令の実行が再度許可される。

図8(b)に示すように、SLD、RMT、およびAMTは連携して動作し、ロード命令の実行を安全に排除するための情報を提供する。