Les CPU de nos Mac : Rosetta 2 et le code x86, Réactions à la publication du 29/06/2025

[Paul Emploi]

Rosetta 2 est apparu sur le Mac mini DTK, avant même son arrivée sur le MacBook Air M1.
Nous avions reporté à l'époque via @Lionel la surprise de son niveau de performance sur du code x86, proche de 85% des performances natives.
Les limites étant le code AVX (vectoriel) et les logiciels créant dynamiquement du code comme le moteur JavaScript de Chrome compilant ce code en x86 dynamiquement.

Contrairement à Rosetta [1] lors du passage à Intel qui interprétait le code PowerPC "a mano" et émulait son fonctionnement, Rosetta 2 est totalement différent.
Bien sur Rosetta [1] exécutait du code PowerPC sur les Mac Intel, mais Rosetta 2 n'exécute aucune code.
Rosetta 2 prend le code pour Mac Intel et le transpile pour Mac ARM: il analyse le code Intel 64 bits et le recompile pour l'architecture ARM 64 bits.
Le code étant alors exécuté nativement, puisque recompilé nativement pour ARM.

Quand Rosetta [1] émulait tel-que un logiciel pour Mac ARM à chaque exécution, Rosetta 2 au premier lancement investi du temps pour le transformer en son équivalent ARM ou plutôt Apple Silicon.
Après le premier lancement, Rosetta [1] continue à émuler lentement, Rosetta 2 n'intervient plus le code étant déjà traduit pour Apple Silicon et stocké sur le SSD.

Sauf que quand le code était émulé instruction par instruction par Rosetta [1], cacochyme, Rosetta 2 offrait 85% des performances natives (hors AVX vectoriel et code dynamiquement créé) sur les Mac ARM. Quasiment l'expérience native sur le DTK!
Ça a tout changé!

Le Mac mini A12z DTK offrait nativement des performances similaires à mon MacBook Pro 15" 2017 Core-i7.
Pour le coup une vraie puce d'iPhone ou d'iPad. Légèrement plus rapide.
Mais les logiciels x86 ne se trainaient pas dessus, ce qui était une vraie surprise, et la faible perte de performance peu visible, voire pas du tout hors certains cas particuliers.

Il y a une astuce propriétaire Apple dans tout cela, car le x86 a des drapeaux créés lors d'opérations arithmétiques qui n'existent pas dans les architectures ARM, ni 32 bits ni 64 bits.
Apple a créé un mode d'exécution propriétaire dans le A12 puis les Apple Silicon Mx, qui n'existe pas dans aucune CPU ARM, pour générer ces drapeaux "en vol" sans incidence sur les performances.

Les SoC Apple ARM sont absolument uniques en ce sens, propriétaires et créés pour Rosetta 2, une très légère modification que normalement ARM interdit absolument. Mais Apple est un des créateur d'ARM!
Ça explique aussi que lorsque Rosetta 2 offre 85% des performances natives, l'émulation Intel de Microsoft sur les PC ARM est très lente car n'implémentant pas d'extension propriétaire.
ARM a accepté qu'Apple ne respecte pas ses règles, mais aucun autre créateur de puces ou SoC ARM n'en a le droit!

La technologie de Rosetta 2 est parfaite, elle a permis de rendre le passage aux Mac ARM indolore pour la plupart, et ça a probablement pour moi été la plus grande surprise venue avec le Mac mini DTK destiné aux développeurs.

Rosetta 2 + M1 ? Pour le prochain épisode!

Lien vers le billet original

[Hebus]

Un binaire n'est qu'un fichier ... c'est ensuite au système d'avoir une stratégie de quoi faire du contenu de document texte ou binaire qu'on lui soumet dans un certain contexte.

Pour macOS un script zsh est un exécutable
Pour windows un .bat est un executable

par exemple


Donc le cache produit par Rosetta2 est un exécutable en toute rigueur, au même titre que l'application origine.

[Benzebut]

Donc le cache produit par Rosetta2 est un exécutable en toute rigueur, au même titre que l'application origine.

Effectivement, mon exemple était trop simpliste, même si un .zsh et consorts sont des fichiers, il s'agit de fichiers particuliers qui sont dans la catégorie des exécutable pour un environnement donné.

Enfin ce n'est pas un "binaire" mais un fichier "exécutable". Comme un script shell par exemple. Ou du Java compilé pour la JVM.
Ou du code PowerPC, ou Intel.

Et c'est sur cette partie que cela fait une différence suite à ces 2 interventions.

Le fichier exécutable généré par Rosetta 2 peut-il fonctionner nativement sur l'architecture ARM indépendamment de Rosetta 2 ? Sinon cela serait comme du Java pour la JVM et avec les mêmes incidences pour une diffusion universelle de ces applications ou de leurs pérennisations entre environnements...

[Paul Emploi]

Le fichier exécutable généré par Rosetta 2 peut-il fonctionner nativement sur l'architecture ARM indépendamment de Rosetta 2 ? Sinon cela serait comme du Java pour la JVM et avec les mêmes incidences pour une diffusion universelle de ces applications ou de leurs pérennisations entre environnements...

Il ne semble pas que ça soit possible: une fois Rosetta 2 désinstallé, les exécutables Intel pourtant déjà traduits (transpilés) ne tournent plus, générant à la place la demande d'installer Rosetta 2!