FEX-Emu desglosa el coste del TSO de x86 en Arm

El proyecto FEX-Emu ha publicado una explicación técnica de por qué ejecutar software x86 en procesadores Arm cuesta tanto, y la respuesta está en el orden de memoria y no en la traducción de instrucciones. Sus cifras muestran que las operaciones no alineadas caen al 8,5% del rendimiento de referencia con el método seguro. FEX es un emulador en modo usuario que ejecuta programas de Linux x86 y x86-64 sobre Arm64.

El problema tiene nombre: Total Store Ordering, abreviado normalmente como TSO. Todo procesador x86 lo ofrece. El artículo de FEX lo describe como la promesa de que "when a memory store occurs, that this will be coherently visible to all other processors in the system". Arm no hace esa promesa de forma predeterminada.

Por qué una promesa más débil cuesta más

Arm usa lo que se llama un modelo de memoria débil. Las escrituras de un núcleo pueden llegar a otros núcleos en un orden distinto al que las escribió el programa, y el procesador puede hacerlo porque así es más rápido.

El software escrito para x86 da por supuesta la garantía más fuerte, a menudo sin decirlo. Un código con varios hilos puede ser correcto en x86 y estar roto en Arm sin ninguna otra razón. Un emulador, por tanto, no puede limitarse a traducir las instrucciones y confiar.

La respuesta segura de FEX usa las instrucciones acquire y release, presentes desde ARMv8.0-a. Esas reimponen el orden correctamente. El artículo describe un coste severo en las operaciones de memoria no alineadas, donde el rendimiento cae al 8,5% de la referencia.

Donde el hardware ayuda

Funciones más nuevas de Arm y el atajo de un fabricante cambian bastante el panorama.

Mecanismo	Efecto informado
acquire y release de ARMv8.0-a	Correcto, pero el rendimiento no alineado cae al 8,5%
Extensiones LRCPC, versiones 1 a 3	Reducen mucho el coste de emular TSO
Interruptor TSO por hardware de Apple Silicon	Casi nativo, con sobrecoste informado de hasta el 15%

A los chips de Apple se les puede indicar que se comporten como x86 en el orden de memoria. Es un interruptor de hardware y no un truco de software, y el artículo sitúa el sobrecoste resultante en torno al 15% como máximo.

Dos casos siguen siendo dolorosos en todo lo demás. Las operaciones de bloqueo partido, es decir, operaciones atómicas que cruzan el límite de una línea de caché, se describen como mucho más lentas en Arm que en x86, donde el artículo da una referencia de unos 660 nanosegundos. De las escrituras de memoria combinadas se informa un ancho de banda 816 veces peor, lo que según el artículo hace injugables ciertos juegos.

El proyecto sigue avanzando alrededor

FEX mejora aquello que sí controla. Phoronix informa de que la versión FEX 2609, del 8 de septiembre de 2026, optimizó la instrucción PMULHRSW y mejoró la detección de código automodificable en juegos hechos con Unity.

Esa versión también redujo la contención de bloqueos en el compilador al vuelo. Las notas dicen que permite que "multiple threads jitting code at the same time block each other less frequently". La mejora declarada llega hasta el doble. Una nueva caché en disco para el código compilado se activa con la variable de entorno FEX_DISKCACHE, de modo que los arranques posteriores son más rápidos.

El proyecto en GitHub recoge los datos que rodean todo esto. Tiene licencia MIT, necesita ARMv8.0 o posterior y ejecuta binarios de 32 y de 64 bits. También se integra con Wine y Proton, y reenvía las llamadas gráficas a las bibliotecas OpenGL y Vulkan del anfitrión.

Qué significa esto para los desarrolladores

Lea esto antes de culpar a su emulador. Si una carga x86 se arrastra en una máquina Arm, el modelo de memoria es el primer sospechoso. Busque accesos no alineados, operaciones atómicas que cruzan líneas de caché y búferes de escritura combinada. Esos tres explican más que la descodificación de instrucciones.

Compruebe qué extensiones de Arm tiene su hardware de destino. El soporte de LRCPC marca la diferencia entre una ruta de emulación cara y otra más barata, y varía por chip y no por fabricante. Esa comprobación pertenece a sus notas de compatibilidad si distribuye software que la gente ejecuta bajo emulación.

No lea las cifras de Apple como el caso general. Su interruptor de hardware es la razón de que un Mac se sienta cercano a lo nativo y un portátil Arm con Linux a menudo no. Las mediciones hechas en Apple Silicon exageran lo que experimentan sus usuarios en otros chips Arm.

Si usted escribe el software emulado, la alineación es la victoria barata. Las operaciones atómicas y los búferes alineados evitan por completo la peor ruta, y ese es un cambio de su lado que ningún emulador puede hacer por usted.