Emulare x86 su ARM è difficile soprattutto per la memoria: FEX-Emu spiega perché

Eseguire software x86 su chip ARM non significa soltanto tradurre istruzioni da un’architettura all’altra. Uno dei problemi più gravosi riguarda la memoria: x86 e ARM applicano infatti regole diverse rispetto all’ordine con cui letture e scritture diventano visibili ai vari core della CPU.

Gli sviluppatori di FEX-Emu, progetto open source che consente di eseguire applicazioni x86 e x86-64 su Linux ARM64, hanno mostrato quanto questa differenza possa incidere concretamente sulle prestazioni.

Il problema principale: riprodurre il comportamento x86 su ARM

x86 utilizza un modello di memoria relativamente rigido, noto come x86-TSO; ARM lascia invece maggiore libertà al processore nel riordinare gli accessi alla memoria. Per eseguire correttamente un programma x86, FEX deve quindi aggiungere vincoli che impediscano ad ARM di effettuare riordinamenti non compatibili con ciò che il software si aspetta.

Sulle CPU ARM meno recenti FEX può essere costretto a tradurre molte normali letture e scritture x86 in istruzioni ARM con semantica acquire e release. In pratica, il processore riceve vincoli più forti sull’ordine degli accessi alla memoria e perde parte della libertà che normalmente usa per ottimizzare l’esecuzione.

FEAT_LRCPC, introdotta nelle versioni più recenti dell’architettura ARM, permette invece di usare istruzioni con garanzie di ordinamento più mirate. FEX può così rispettare il comportamento richiesto dal codice x86 senza imporre sempre le forme di sincronizzazione più pesanti. Il risultato pratico è meno lavoro per il processore e, in alcuni carichi, una penalizzazione inferiore durante l’emulazione.

Apple ha scelto una soluzione ancora più diretta: i SoC Apple Silicon dispongono di una modalità hardware compatibile con il modello x86-TSO. Rosetta 2 può quindi eseguire gran parte del codice x86 senza aggiungere continuamente barriere e istruzioni di sincronizzazione. È uno dei motivi per cui il supporto hardware specifico può fare una differenza enorme nell’emulazione.

Dove l’emulazione può perdere molto in prestazioni

Un altro problema nasce dal fatto che x86 tollera con grande libertà accessi alla memoria che su ARM richiedono più attenzione.

Gli sviluppatori spiegano che in alcuni casi FEX non può tradurre direttamente un’operazione x86 nella corrispondente istruzione ARM: deve intercettare il problema e usare una sequenza alternativa più costosa. La situazione diventa ancora più pesante con le operazioni atomiche, cioè quelle che il software multithread usa per modificare dati condivisi senza rischiare risultati incoerenti.

Se l’hardware ARM non può gestire direttamente l’operazione, può essere necessario coinvolgere anche il kernel Linux. Il continuo passaggio tra programma, kernel ed emulatore introduce un overhead che, se ripetuto migliaia di volte, può incidere pesantemente sulle prestazioni.

Come accennato in precedenza, le CPU ARM più recenti stanno riducendo parte di questi costi attraverso nuove funzioni hardware. FEX cita, per esempio, i core Qualcomm Oryon-3, che gestiscono meglio alcune operazioni atomiche non allineate. Restano però casi estremi, come le operazioni che interessano contemporaneamente due cache line, molto difficili da riprodurre con le stesse garanzie offerte da x86.

Il problema può coinvolgere anche la GPU

Le conseguenze diventano particolarmente evidenti nei videogiochi. Quando un sistema usa una GPU dedicata collegata tramite PCIe, CPU e scheda grafica devono scambiarsi continuamente dati attraverso specifiche aree di memoria. FEX deve mantenere anche qui il comportamento previsto da x86 e, su alcune piattaforme ARM, le istruzioni necessarie per farlo possono ridurre drasticamente la velocità dei trasferimenti.

Gli sviluppatori citano casi limite in cui titoli come Hollow Knight: Silksong e Subnautica 2 sono scesi sotto 1 FPS.

Le piattaforme con GPU integrata possono trovarsi in una situazione migliore perché CPU e GPU condividono la stessa memoria e possono evitare parte di questi passaggi costosi.

La conclusione pratica è importante: una CPU ARM molto veloce nei benchmark nativi non è necessariamente altrettanto veloce quando deve eseguire software x86. Nell’emulazione contano anche il modo in cui il processore gestisce memoria, operazioni atomiche e sincronizzazione con la GPU.

Per FEX, quindi, il collo di bottiglia di solito non è affatto la traduzione delle istruzioni: nel caso di tanti programmi, il vero problema è riuscire a riprodurre in modo efficiente comportamenti che x86 garantisce direttamente in hardware.

Cosa significa tutto questo per chi usa un dispositivo ARM?

Le applicazioni native ARM restano sempre la scelta migliore perché non richiedono la traduzione del codice. Su Windows 11 on Arm, per esempio, Prism permette di eseguire automaticamente applicazioni x86 e x64 e Microsoft ha introdotto ottimizzazioni specifiche per ridurre consumo di CPU e perdita di prestazioni. L’emulazione riguarda però il codice in modalità utente: eventuali driver devono comunque esistere in versione ARM64.

È quindi possibile che un vecchio programma funzioni perfettamente mentre una periferica, un software di virtualizzazione o un’applicazione che dipende da un driver proprietario non funzionino affatto. Prima di acquistare un PC ARM conviene controllare soprattutto questi componenti, più che limitarsi a verificare se il programma principale si apre.

Emulazione e prestazioni del software x86 Windows su ARM

Anche le prestazioni dipendono dal tipo di software. Browser, applicazioni da ufficio e molti programmi comuni dispongono ormai di versioni ARM native; Microsoft cita tra gli altri Chrome, Spotify, Zoom, Blender, Affinity e DaVinci Resolve.

La situazione può cambiare con software più pesante, vecchi programmi x86, plug-in, giochi o applicazioni che effettuano molte operazioni particolari sulla memoria.

In questi frangenti entrano in gioco i problemi descritti dagli sviluppatori di FEX: due programmi x86 possono comportarsi in maniera completamente diversa sullo stesso chip ARM.

Su Windows esiste anche un controllo pratico utile nei casi problematici: facendo clic con il tasto destro sull’eseguibile e aprendo Proprietà, Compatibilità, Windows on Arm, è possibile modificare alcune impostazioni di emulazione di Prism. Microsoft precisa però che aumentare la compatibilità può significare rinunciare a parte delle prestazioni.

Lo stesso principio vale su macOS: Rosetta traduce automaticamente le applicazioni Intel sui Mac Apple Silicon, ma Apple sta ormai spingendo gli sviluppatori verso versioni native e ha già avvisato che il supporto alle applicazioni Intel terminerà in una futura versione di macOS.