Midterms 2026Wer nach unseren Maßstäben Ihre Stimme verdientZum Leitfaden →
GESCHRIEBEN IN KLAREM DEUTSCH.
CLAY TRIBUNE.
Anzeige

Die Geißel der x86-Emulation: Warum FEXs Speichermodell-Hack teuer ist

FEX emuliert x86-TSO-Speicher auf ARM, doch die Kosten sind immens – jede Ladeoperation wird zu einem Acquire, jeder Speichervorgang zu einem Release.

Von mitch·4 Min. Lesezeit
A glowing circuit board showing binary data streaming between an x86 and an ARM processor chip.

FEX hat ein Problem an der Backe, und es heißt x86-TSO. Das Unternehmen schreibt Emulatoren für x86-Systeme, und das Speichermodell, das diese Systeme verwenden, ist streng geordnet – jeder Store ist für jeden anderen Prozessor sichtbar, jeder Load sieht jeden früheren Store. Das ist das Gegenteil der Funktionsweise moderner ARM-CPUs, bei denen der Speicher schwach geordnet ist und Stores in Caches liegen, bis sie herausgeschrieben werden.

Das Ergebnis ist ein ständiger Kampf. FEX verwandelt jeden x86-Speicher-Load in eine ARM-Load-Acquire-Instruktion. Jeder x86-Store wird zu einer ARM-Store-Release-Instruktion. Das verschafft dem Emulator dieselbe Speichersemantik wie x86, ist aber ein teurer Trick. ARM-CPUs wurden nicht dafür gebaut, dass Acquire- und Release-Instruktionen die überwiegende Mehrheit dessen sind, was sie ausführen, und FEX weiß das.

Die Speichermodell-Lücke

Ein Speichermodell ist eine Reihe von Regeln dafür, wie sich Speicherzugriffe zueinander verhalten. x86-TSO ist das strenge Ende des Spektrums. Ein Programmierer kann davon ausgehen, dass ein Store, wenn er stattfindet, für alle Prozessoren im System sichtbar ist. Ein Load sieht alle Stores vor ihm, logisch abgeschlossen oder zumindest sichtbar. Die Stores ordnen die Sichtbarkeit der Loads, woher der Name stammt.

Anzeige

ARMs Modell ist das andere Ende. Reguläre Loads und Stores sind standardmäßig nicht kohärent über Prozessoren hinweg. Ein Store macht seine Cacheline nicht sofort für andere Kerne sichtbar. Ein Prozessor, der Daten aus dem Speicher lädt, in die ein anderer Prozessor geschrieben hat, sieht nicht garantiert den aktualisierten Wert. Das ist die schwache Konsistenz, die ARM-CPUs ermöglicht, Strom zu sparen und die meiste Zeit effizient zu laufen.

Die beiden Modelle sind nicht dasselbe. Konsistenz und Atomarität sind verwandt, aber getrennt. ARM führte Load-Acquire- und Store-Release-Instruktionen ein, um Ordnung zu erzwingen, und in C++-Begriffen entsprechen diese std::atomic’s memory_order_acquire und memory_order_release. ARM nennt das resultierende Modell Release Consistency sequentially consistent (RCsc). Acquire-Loads müssen sequenziell ohne Umordnung beobachtet werden. Store-Releases müssen „barrier-ordered-before“-Semantik erfüllen. Die ältere Speicherbarrieren-Instruktion war kostspielig, und diese neuen Instruktionen beseitigten sie.

ARMv8.0-a und die Kosten

FEX beginnt seine Emulationsreise mit ARMv8.0-a, wo die Strategie einfach ist: alle x86-Ladevorgänge in Acquire-Befehle und alle x86-Speichervorgänge in Release-Befehle umzuwandeln. Das verleiht FEX dieselbe Speichersemantik wie x86, doch das Unternehmen gibt zu, dass es strenger als nötig ist. Die Microbenchmarks zeigen die Kosten. Es ist überaus kostspielig, TSO auf diese Weise zu emulieren, und ARM-CPUs wurden nicht dafür entworfen, dass diese seltenen Befehle plötzlich die große Mehrheit dessen ausmachen, was sie ausführen.

Das Unternehmen testete dies mit einem Microbenchmark, der hardwarefreundlich ist. Keine kniffligen Randfälle, nur Speicherzugriffe im Normalfall. Der Graph erzählt einiges. Die Spalten Load und Store stellen den Basiswert der Leistung dar.

Die Rangfolge der Befehle

  1. Die Emulationsstrategie von ARMv8.0-a: alle x86-Ladevorgänge werden zu Acquire-Befehlen, alle x86-Speichervorgänge werden zu Release-Befehlen.
  2. Der ältere Speicherbarriere-Befehl: kostspielig und ersetzt durch die neueren Acquire- und Release-Befehle.
  3. Die neueren Load-Acquire- und Store-Release-Befehle: billiger als der ältere Barriere-Befehl, aber immer noch teuer, wenn sie die große Mehrheit der Ausführung ausmachen.

Was wir bisher wissen

  • x86-TSO ist ein strenges Speichermodell, bei dem Speichervorgänge für alle Prozessoren sichtbar sind und Ladevorgänge alle früheren Speichervorgänge sehen.
  • ARMs Modell ist schwach konsistent, was bedeutet, dass Speichervorgänge für andere Kerne nicht sofort sichtbar sind.
  • Die Emulation von ARMv8.0-a wandelt x86-Ladevorgänge in Acquire-Befehle und Speichervorgänge in Release-Befehle um.
  • Microbenchmarks zeigen, dass der Ansatz überaus kostspielig ist.
  • Der ältere Speicherbarriere-Befehl wurde durch Load-Acquire und Store-Release ersetzt.

Das Urteil

FEX hat eine funktionierende Lösung, aber sie ist teuer. Das Unternehmen ist sich der Kosten bewusst und hat Microbenchmarks, um dies zu belegen.

Die Lehre ist, dass Emulation nicht kostenlos ist. Jede Abstraktion kostet etwas, und Speichermodelle gehören zu den am schwersten zu überbrückenden Abstraktionen.

Die Geschichte ist für jeden lesenswert, der sich dafür interessiert, wie sich der Speicher in einem Computer verhält.

Quellenmaterial: „The scourge of x86 emulation“, fex-emu.com.

Das Notizbuch

Das Notizbuch abonnieren.

Die besten Geschichten des Tages und jedes neue Urteil, in klarem Deutsch, um sieben im Postfach. Eine Mail am Tag, nicht mehr.

Wir schicken eine Bestätigungsmail. Jede Ausgabe hat einen Abmeldelink, ein Klick genügt.

Anzeige

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Als Amazon-Partner verdient Clay Tribune an qualifizierten Verkäufen.