Laut den Entwicklern von FEX-Emu ist es deutlich schwieriger als gedacht, das Arbeitsmodell des Computerspeichers zu emulieren, sobald Caches und mehrere Prozessoren ins Spiel kommen. Das Total Store Ordering-Modell von x86 bietet starke Garantien für die Sichtbarkeit von Speicheroperationen, während das schwächere Modell von ARM aus Leistungsgründen eine Neuordnung erlaubt. Auch wenn Emulatoren dies mit Acquire-/Release-Operationen ausgleichen können, steigen die Kosten; die LRCPC-Erweiterungen und der x86-kompatible TSO-Modus auf Apple Silicon verringern den Aufwand.
Nicht kompatibel ausgerichtete Zugriffe und atomare Operationen verschärfen die Probleme. FEX kann Ausrichtungsfehler erkennen und Barrieren in den übersetzten Code einfügen; Split-Lock-Operationen können sich jedoch unter Einbeziehung des Kernels und von Signal-Handlern um das Hundert- oder Tausendfache gegenüber der normalen Geschwindigkeit verlangsamen. Die Oryon-Kerne von Qualcomm und die Linux-Optimierungen von Valve mildern einige Probleme.
Bei Write-Combined-Speicher, in den auf die GPU geschrieben wird, fehlen gleichwertige ARM-Mechanismen; im schlimmsten Fall kann die Bandbreite um 800× sinken und Spiele auf unter 1 FPS drücken. UMA-Systeme erzielen bessere Ergebnisse. Bei der Emulation geht es weniger um die Übersetzung von Instruktionen als um die Reproduktion architektonischer Annahmen.
Warum das wichtig ist
Dieser technische Unterschied erschwert es, in Emulatoren, die x86-Software auf ARM-basierter Hardware ausführen, Kompatibilität und Leistung gleichzeitig aufrechtzuerhalten. Da das Problem nicht auf die Übersetzung von Prozessorinstruktionen beschränkt ist, können Mehrkernnutzung, atomare Operationen und der Zugriff auf den GPU-Speicher auf unterschiedlicher Hardware zu jeweils anderen Ergebnissen führen. Daher hängen die Resultate neben der verwendeten Prozessor- und Speicherarchitektur auch davon ab, welche Optimierungen das Betriebssystem und der Emulator anwenden; Apple Silicon, Oryon, die Optimierungen von Valve und UMA-Designs zeigen, dass sich diese Unterschiede verringern lassen. Offen bleibt, bei welchen Workloads diese Verbesserungen ausreichen und in welchem Umfang sich die für die Kompatibilität erforderlichen zusätzlichen Kosten dauerhaft tragen lassen.