FEX-Emu erklärt die Kosten von x86-TSO auf Arm

Das Projekt FEX-Emu hat eine technische Darstellung veröffentlicht, warum x86-Software auf Arm-Prozessoren so viel kostet. Die Antwort liegt bei der Speicherordnung und nicht bei der Befehlsübersetzung. Die Zahlen zeigen, dass unausgerichtete Zugriffe beim sicheren Verfahren auf 8,5% des Ausgangsdurchsatzes fallen. FEX ist ein Emulator im Benutzermodus, der x86- und x86-64-Linux-Programme auf Arm64 ausführt.

Das Problem hat einen Namen: Total Store Ordering, meist als TSO abgekürzt. Jeder x86-Prozessor bietet es. Der FEX-Artikel beschreibt es als das Versprechen, dass "when a memory store occurs, that this will be coherently visible to all other processors in the system". Arm gibt dieses Versprechen standardmäßig nicht.

Warum ein schwächeres Versprechen mehr kostet

Arm nutzt ein sogenanntes schwaches Speichermodell. Schreibzugriffe eines Kerns können andere Kerne in anderer Reihenfolge erreichen, als das Programm sie geschrieben hat. Der Prozessor darf das, weil es schneller ist.

Für x86 geschriebene Software setzt die stärkere Zusage voraus, oft ohne es zu sagen. Mehrfädiger Code kann auf x86 korrekt und auf Arm fehlerhaft sein, ohne weiteren Grund. Ein Emulator kann die Befehle daher nicht einfach übersetzen und hoffen.

FEX antwortet sicher mit den Acquire- und Release-Befehlen, die es seit ARMv8.0-a gibt. Sie stellen die Ordnung korrekt wieder her. Der Artikel nennt die Kosten bei unausgerichteten Speicherzugriffen als schwer: Der Durchsatz fällt auf 8,5% des Ausgangswerts.

Wo die Hardware hilft

Neuere Arm-Funktionen und die Abkürzung eines Herstellers ändern das Bild deutlich.

Mechanismus	Berichtete Wirkung
Acquire und Release aus ARMv8.0-a	Korrekt, aber unausgerichteter Durchsatz fällt auf 8,5%
LRCPC-Erweiterungen, Versionen 1 bis 3	Senken die Kosten der TSO-Nachbildung erheblich
Hardware-TSO-Schalter von Apple Silicon	Nahezu nativ, Mehraufwand bis etwa 15%

Apples Chips lassen sich anweisen, sich bei der Speicherordnung wie x86 zu verhalten. Das ist ein Hardwareschalter und kein Softwaretrick. Der Artikel beziffert den daraus folgenden Mehraufwand auf höchstens rund 15%.

Zwei Fälle bleiben überall sonst schmerzhaft. Split-Lock-Operationen, also atomare Operationen über eine Cache-Zeilengrenze hinweg, gelten auf Arm als dramatisch langsamer als auf x86, wo der Artikel einen Ausgangswert von etwa 660 Nanosekunden nennt. Für Write-Combine-Speicherungen wird eine 816-mal schlechtere Bandbreite berichtet, was laut Artikel bestimmte Spiele unspielbar macht.

Das Projekt liefert weiter daran vorbei

FEX verbessert weiterhin das, was es selbst steuert. Phoronix berichtet, dass die Veröffentlichung FEX 2609 vom 8. September 2026 den Befehl PMULHRSW optimierte und die Erkennung von selbstveränderndem Code in Unity-Spielen verbesserte.

Diese Veröffentlichung senkte außerdem die Sperrkonkurrenz im Just-in-time-Compiler. Die Anmerkungen sagen, sie lasse "multiple threads jitting code at the same time block each other less frequently". Der genannte Zugewinn beträgt bis zum Doppelten. Ein neuer Zwischenspeicher für übersetzten Code auf der Festplatte wird über die Umgebungsvariable FEX_DISKCACHE eingeschaltet, sodass spätere Starts schneller sind.

Das Projekt auf GitHub nennt die übrigen Eckdaten. Es steht unter MIT-Lizenz, verlangt ARMv8.0 oder neuer und führt sowohl 32-Bit- als auch 64-Bit-Binärdateien aus. Es arbeitet zudem mit Wine und Proton zusammen und reicht Grafikaufrufe an die OpenGL- und Vulkan-Bibliotheken des Wirts weiter.

Was das für Entwickler bedeutet

Lesen Sie das, bevor Sie den Emulator beschuldigen. Wenn eine x86-Last auf einer Arm-Maschine kriecht, ist das Speichermodell der erste Verdächtige. Suchen Sie nach unausgerichteten Zugriffen, nach Atomics über Cache-Zeilengrenzen und nach Write-Combine-Puffern. Diese drei erklären mehr als die Befehlsdekodierung.

Prüfen Sie, welche Arm-Erweiterungen Ihre Zielhardware hat. LRCPC-Unterstützung entscheidet zwischen einem teuren und einem günstigeren Emulationspfad, und sie unterscheidet sich je Chip statt je Hersteller. Diese Prüfung gehört in Ihre Kompatibilitätshinweise, wenn Sie Software verteilen, die Menschen unter Emulation ausführen.

Lesen Sie Apples Zahlen nicht als Regelfall. Der Hardwareschalter ist der Grund, warum sich ein Mac nahezu nativ anfühlt und ein Arm-Laptop mit Linux oft nicht. Messungen auf Apple Silicon überzeichnen, was Nutzer anderer Arm-Chips erleben.

Wer die emulierte Software selbst schreibt, gewinnt am billigsten über Ausrichtung. Ausgerichtete Atomics und Puffer vermeiden den schlimmsten Pfad ganz, und das ist eine Änderung auf Ihrer Seite, die kein Emulator für Sie vornehmen kann.