出来事の日付：2026年9月18日。

FEXエミュレーターの開発者らは、Armプロセッサーでx86アプリケーションを動かすうえで最も難しい問題の一つについて、技術的な解説を公開した。大きく異なるメモリモデルを持つ二つのアーキテクチャの間で、ソフトウェアが期待する処理順序の規則を維持するという問題だ。通常のメモリ読み書きはプログラム実行の中心にあるため、この問題はエミュレーションされるほぼすべてのアプリケーションに影響する。

X86プロセッサーはTotal Store Ordering（TSO）と呼ばれるモデルを採用する。単純化すると、書き込みがいつ見えるようになるか、後の読み込みが複数のコア間でそれとどう関係するかについて、比較的強い保証をプログラマーに与える。一方、Armの標準モデルはより弱く、さらに多くの並べ替えを許容することで、性能や電力効率を高める自由度をハードウェアに与えている。Arm向けにコンパイルされたソフトウェアは、必要な箇所で順序を明示的に要求できるが、エミュレーターはx86用にコンパイルされたコードに織り込まれた前提を再現しなければならない。

Armv8.0-A向けのFEXの基本的な解決策では、x86のロードをArmのロード・アクワイア命令に、x86のストアをストア・リリース命令に変換する。これらの操作は並べ替えを制約し、x86プログラムが期待するものに近い動作を実現する。ただし、この変換は安全側に寄せられている。ゲスト側の操作が実際に必要とする以上に厳格な順序を課す場合があり、通常のプログラムに含まれる膨大なメモリ命令にアクワイアやリリースの動作を適用すれば、負荷が増える。

同プロジェクトのベンチマークは、その負荷を単一の性能値で見積もれない理由を示している。試験した5種類のプロセッサーのうち複数で、通常のロードをアクワイア・ロードに置き換えると大幅に遅くなった。試験した経路ではAmpereOneのリリース・ストアの結果が特に悪く、AppleのM1も一部のアクワイア・ロードおよびRCpcロードで基準値を下回った。より新しいCortex-X4とCortex-X925はこれらの命令をよりうまく処理し、QualcommのOryon 3の結果は最適化の優先事項の違いを示唆した。これらはFEXチームのマイクロベンチマークによる観測であり、あらゆる処理負荷に対するプロセッサーの総合順位ではない。

Armは負荷を軽減できる手段を追加してきた。Armv8.3以降、アーキテクチャはロード・アクワイアRCpc命令への対応を必須としており、この命令は一部の変換上の要件により適した順序保証を提供する。ただし、メモリ順序と原子性は別の概念であり、実際の命令列は、マルチスレッドのx86ソフトウェアが依存する動作を依然として維持する必要がある。高速でも、ときどき不正な順序を観測可能にする変換は、まれで極めて解決困難なバグを生みかねない。

したがって、これは単に一方の命令セットを他方へ変換する以上に広い問題である。動的変換器は、キャッシュの動作、コア間の相互作用、個々のArm実装の違いも考慮しなければならない。同じ世代のアーキテクチャに準拠しているチップ同士であっても、一方では高性能な方法が、他方では大きな負荷になる場合がある。

FEXの分析は、算術演算やグラフィックスのベンチマークだけではx86エミュレーションの品質を判断できない理由を説明している。変換後のアプリケーションがありふれた処理をしているように見えても、共有メモリの正しい動作を維持するために相当な資源が消費される場合がある。したがって改善には、より賢い変換戦略と、ネイティブソフトウェアで一般的に必要な頻度を大幅に上回って使っても効率的な順序制御命令を提供するArmハードウェアの両方が必要となる。