なぜx86‑TSOのエミュレーションはARMでパフォーマンスのボトルネックとなるのか、そしてFEXはどう対処しているのか

核心的な問題：弱順序ARM ISA上でのx86‑TSOエミュレーション

ARMの弱順序モデル上でx86のTotal Store Ordering (TSO) メモリモデルをエミュレートすると、すべてのx86ロードをARMの load‑acquire に、すべてのストアを store‑release に変換する必要があるため、大きなパフォーマンス低下を招きます。これらの命令は通常のロード/ストアよりもはるかにコストが高く、本来は主要な命令クラスとして使用されることを意図していません。

なぜx86‑TSOがアプリケーションにとって重要なのか

x86‑TSOは、ストアがすべてのコアから見えるようになってからでなければ後続のロードがそれを観測できないことを保証しており、プログラマは余分なフェンス命令なしでメモリについて推論できます。この厳密な整合性はx86 ISAに組み込まれており、事実上すべてのPCゲームや多くのレガシーアプリケーションがこれに依存しています。

ARMの弱整合性モデル

ARMのデフォルトのロードおよびストアは即座に整合性が取れるわけではありません。ストアは明示的にフラッシュされるまでプライベートキャッシュラインに留まる可能性があり、ロードは古いデータを読み取る可能性があります。順序性を確保するために、ARMは軽量なバリアとして機能する load‑acquire および store‑release 命令（「RCsc」モデル）を提供しています。

初期のエミュレーション戦略：至る所でのAcquire/Release

FEXは当初、すべてのx86ロードをARMのload‑acquireに、すべてのストアをstore‑releaseにマッピングしていましたが、これは機能的には正しいものの非常にコストがかかるものでした。 5つのCPUでのマイクロベンチマークでは、acquire‑loadで最大50%の速度低下が見られ、一部のコア（AmpereOneなど）ではrelease‑storeのスループットが劇的に低下しました。

スプリットロックの課題

x86プログラムは、キャッシュライン境界をまたぐ非整列アクセス（「スプリットロック」）を頻繁に行いますが、これはx86ではアトミックであるものの、ARMではアライメントフォールトを引き起こします。 ARMはacquire/release命令に対して自然なアライメントを要求します。アライメントがずれたアクセスはフォールトをトリガーし、FEXは実行時にJITにパッチを当て、データメモリバリア（DMB）を挿入して再試行することを余儀なくされます。

"アライメントフォールトがこれらのパッチポイントで発生すると、FEXはフォールトをキャプチャし、コードをload‑acquire/store‑release命令から 基本的な 等価ロード‑ストア命令にパッチを当て、その命令をデータメモリバリアで囲みます。" – FEX記事

フォールト処理パスには、スプリットロックごとにカーネルからユーザ空間への往復が含まれており、これはネイティブ実行よりも数千倍遅くなる可能性があります。

役立つARM拡張機能

LRCPC (FEAT_LRCPC, LRCPC2, LRCPC3)

LRCPCファミリーは、重いacquire‑loadのペナルティなしでx86‑TSOセマンティクスに一致する「Release Consistency processor‑consistent」ロード命令を追加します。ベンチマークによると、LRCPC‑loadはほとんどのCPUでベースラインに近いスループットを達成しています。

FEAT_LSE2

FEAT_LSE2は、acquire/LRCPC/Release命令のアライメント要件を16バイト単位に緩和しますが、64バイト（キャッシュライン）をまたぐ場合は依然としてフォールトが発生します。ほとんどのx86アトミック操作は64バイトのキャッシュライン全体にまたがるため、スプリットロックに対する効果はわずかです。

AppleのハードウェアTSOモード – 理想的な解決策

Apple Siliconは、通常のARMロード/ストアがx86‑TSOセマンティクスに従うようにするハードウェアトグルを実装しており、acquire/releaseやLRCPC命令の必要性を排除しています。 M1では、整列アクセスと非整列アクセスのパフォーマンスは事実上同一であり、唯一のオーバーヘッドはTSOモード有効時にストアでわずか5%の速度低下があるだけです。

"Appleのハードウェアは、x86‑TSOメモリモデルのサポートを直接追加しました。CPU機能が切り替わると、彼らの 通常の ロード/ストアARM命令は、x86が必要とするものと一致するように動作を変更します。" – FEX記事

FEXがこの機能（Asahi Linux経由など）を検出すると、ハードウェアTSOモードを有効にして、同じ「無料の」パフォーマンス向上を得ることができます。

アトミックRMW命令：x86 LOCKからARMへのマッピング

ARMv8.1‑aは、18個のすべてのx86 LOCKプレフィックス付きRMW操作（例： LOCK ADD → ldaddal）に対して1対1の等価物を提供します。 ただし、同じアライメントフォールトの問題が適用されます。キャッシュラインをまたぐ非整列のアトミックRMWは、依然としてコストのかかるフォールト処理パスを必要とします。

非キャッシュ（ライトコンバイン）メモリ – 致命的な問題

ゲームがVulkanの VK_MEMORY_HOST_CACHED_BIT をクリア（ライトコンバインバッファ）して使用する場合、ARMのLRCPCロードは劇的に遅くなり、ストアはx86よりも最大816倍遅くなる可能性があります。これは、非キャッシュメモリがすべてのロードをシステムメモリへ強制し、LRCPCが余分なバリアを追加するためです。

"これらすべての中で最悪のケースは、Zenのストアパフォーマンスと比較して、ストアパフォーマンスがいかにひどいかということです。これは基本的に致命的な問題です。最大 816倍 も帯域幅が悪化します！" – FEX記事

FEXはUMAシステムではドライバにキャッシュされたバッファを使用させることでこの問題を緩和していますが、PCIe‑GPUシステムでは問題は未解決のままです。

ベンダー固有の調査結果

CPU	整列ロード/ストア	非整列ペナルティ（ロード）	非整列ペナルティ（ストア）
AmpereOne	ベースライン ≈ 28 GB/s ストア	≈ 0% (ロード)	~8.5% 速度低下 (ストア)
Cortex‑X4	11.5 GB/s ロード, 6.7 GB/s ストア	~50% 速度低下 (両方)
Cortex‑X925	X4と同様、より高い絶対帯域幅
Oryon‑3	整列LRCPC‑loadはベースラインと一致; ストア ≈ ベースラインの68%; 非整列ストア ≈ 43%
Apple M1	ストアで < 5% の速度低下; ロードは変化なし – ハードウェアTSOがアライメントオーバーヘッドを排除

スプリットロックに対する将来のハードウェアサポートの提案

実現可能なハードウェア修正は、アライメントフォールトを発生させることなく64バイト境界をまたいでアトミックに動作できる128ビットの CASP です。この操作は失敗して再試行される可能性があり、ARMのLL/SCモデルを活用して前進を保証できます。

開発者およびアーキテクトへの要点

ハードウェアサポートなしでARM上でx86‑TSOをエミュレートするのは高コストです – acquire/release命令とスプリットロックのフォールト処理がオーバーヘッドの大部分を占めます。
LRCPC拡張はベースラインのロード/ストアパフォーマンスを劇的に向上させますが、非整列アトミックやライトコンバインのケースは解決しません。
AppleのハードウェアTSOモードは最適な道を示しています：通常のロード/ストアをx86‑TSOに従わせる単一のトグルにより、ネイティブに近いパフォーマンスが得られます。
非キャッシュ（ライトコンバイン）メモリは、PCIe‑GPUシステムにとって依然として重大なボトルネックです；ドライバレベルの回避策が現在唯一の実用的な緩和策です。
将来のARM拡張（スプリットロックを認識する CASP など）は、キャッシュラインをまたぐアトミック操作の残りのパフォーマンスギャップを埋める可能性があります。

コミュニティの反応

"Appleは6年前、x86エミュレーションが重要になったときに、チップにx86互換のメモリ順序付けモードを追加するだけでこの問題を解決しました。Appleのチップが業界をリードするもう一つの方法です。" – @modeless

"FEXは素晴らしいです。私が遭遇する問題のほとんどはアンチチート関連ですが、アーキテクチャのハードルを考えると、エミュレータ自体は驚くほど高速です。" – @sureglymop

"この記事は、ARMが最も緩やかでx86が最も厳格であるという一般的な主張を繰り返していますが、緩やかなモデルが必ずしも多くの利点を持つわけではありません。" – @pdw (外部議論へのリンク)

結論

ARM上でx86‑TSOをエミュレートすることは、2つのISAが相反するメモリ順序付け保証を強制するため、根本的に困難です。現在の最良のソフトウェアアプローチ（acquire/release → LRCPC → ハードウェアTSO）は、ほとんどのワークロードで許容可能なパフォーマンスをもたらしますが、スプリットロックと非キャッシュメモリは依然として深刻な速度低下を引き起こします。継続的なARM ISAの拡張と、AppleのようなハードウェアTSOモードのより広範な採用が、将来のARMプラットフォーム上でシームレスで高性能なx86エミュレーションを実現するための最も有望な道です。