According to FEX-Emu developers, emulating the computer memory model is much harder than it seems once caches and multiple processors come into play. x86’s Total Store Ordering model provides strong guarantees for the visibility of memory operations, while ARM’s weaker model allows reordering for performance. Although emulators can compensate for this with acquire/release operations, the cost increases; LRCPC extensions and the x86-compatible TSO mode on Apple Silicon reduce the overhead.
Misaligned accesses and atomic operations make the problems worse. FEX can detect alignment faults and add barriers to translated code; split-lock operations, meanwhile, can become hundreds or thousands of times slower than normal by resorting to the kernel and signal handlers. Qualcomm’s Oryon cores and Valve’s Linux optimization reduce some of these problems.
ARM equivalents for write-combined memory written to the GPU remain inadequate; in the worst case, bandwidth can drop by 800×, reducing games to below 1 FPS. UMA systems deliver better results. Emulation is based less on translating instructions than on reproducing architectural assumptions.
Why it matters
This technical difference makes it difficult for emulators that run x86 software on ARM-based hardware to preserve compatibility and performance at the same time. Since the problem is not limited to translating processor instructions, areas such as multicore use, atomic operations, and access to GPU memory can produce different results on different hardware. As a result, the outcome depends not only on the processor and memory architecture in use, but also on which optimizations the operating system and emulator implement; Apple Silicon, Oryon, Valve optimizations, and UMA designs show that this gap can be reduced. The open question is which workloads these improvements will be sufficient for and to what extent the additional cost required for compatibility can be sustained.