FEX-Emu breaks down the cost of x86 TSO on Arm

The FEX-Emu project has published a technical account of why running x86 software on Arm processors costs so much, and the answer is memory ordering rather than instruction translation. Its figures show unaligned operations falling to 8.5% of baseline throughput under the safe approach. FEX is a usermode emulator that runs x86 and x86-64 Linux programs on Arm64.

The problem has a name: Total Store Ordering, usually shortened to TSO. Every x86 processor provides it. The FEX article describes it as the promise that "when a memory store occurs, that this will be coherently visible to all other processors in the system". Arm makes no such promise by default.

Why a weaker promise costs more

Arm uses what is called a weak memory model. Writes from one core can reach other cores in a different order than the program wrote them, and the processor is free to do that because it is faster.

Software written for x86 assumes the stronger guarantee, often without saying so. Multi-threaded code can be correct on x86 and broken on Arm for no other reason. An emulator therefore cannot simply translate the instructions and hope.

FEX's safe answer uses the acquire and release instructions present since ARMv8.0-a. Those reimpose the ordering correctly. The article reports the cost as severe on unaligned memory operations, where throughput drops to 8.5% of baseline.

Where the hardware helps

Newer Arm features and one vendor's shortcut change the picture considerably.

Mechanism	Effect reported
ARMv8.0-a acquire and release	Correct, but unaligned throughput falls to 8.5% of baseline
LRCPC extensions, versions 1 to 3	Substantially reduce the cost of emulating TSO
Apple Silicon hardware TSO switch	Near-native, with overhead reported at up to about 15%

Apple's chips can be told to behave like x86 for memory ordering. That is a hardware switch rather than a software trick, and the article puts the resulting overhead at roughly 15% at most.

Two cases stay painful everywhere else. Split-lock operations, meaning atomic operations that straddle a cache-line boundary, are described as dramatically slower on Arm than on x86, where the article gives a baseline around 660 nanoseconds. Write-combine memory stores are reported at 816 times worse bandwidth, which the article says makes certain games unplayable.

The project keeps shipping around it

FEX itself continues to improve on the parts it controls. Phoronix reports that the FEX 2609 release on September 8, 2026 optimised the PMULHRSW instruction and improved detection of self-modifying code in Unity games.

That release also reduced lock contention in the just-in-time compiler. The release notes say it lets "multiple threads jitting code at the same time block each other less frequently". The claimed uplift is up to two times. A new on-disk cache for compiled code is switched on with the FEX_DISKCACHE environment variable, so later runs start faster.

The project on GitHub states the surrounding facts. It is MIT licensed, needs ARMv8.0 or newer, and runs both 32-bit and 64-bit binaries. It also integrates with Wine and Proton, forwarding graphics calls to the host's own OpenGL and Vulkan libraries.

What this means for developers

Read this before blaming your emulator. If an x86 workload crawls on an Arm machine, the memory model is the first suspect. Look for unaligned accesses, atomics crossing cache lines, and write-combined buffers. Those three explain more than instruction decoding does.

Check which Arm extensions your target hardware has. LRCPC support is the difference between an expensive emulation path and a cheaper one, and it varies by chip rather than by vendor. That check belongs in your compatibility notes if you distribute software people run under emulation.

Do not read Apple's numbers as the general case. Its hardware switch is why a Mac feels close to native and a Linux Arm laptop often does not. Benchmarks taken on Apple Silicon will overstate what your users on other Arm chips experience.

If you write the software being emulated, alignment is the cheap win. Aligned atomics and buffers avoid the worst path entirely, and that is a change on your side that no emulator can make for you.