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]

Clairement impressionnant d’efficacité quand couplé au boulot fait avec docker je peux compiler du code 32 bits dans du Linux Intel … RockyLinux ou autres déclinaisons et faire tout mon dev en local sur un Mac Apple Silicon

Super outils de travail dans un MBP M4 pro avec 48GB !

[g4hd]

Rosetta 2 mérite le Nobel des Systèmes !
Sauf qu'Apple est bien capable de le tuer à tout moment, sur un coup de tête imprévisible.
Et ça peut arriver au prochain macOS Mac silicon only.

Les éditeurs des applis x86 qui n'auront toujours pas été réécrites sont les responsables pas coupables, selon la phraséologie bien connue en France !

[FredStrasbourg]

Sauf qu'Apple est bien capable de le tuer à tout moment, sur un coup de tête imprévisible.
Et ça peut arriver au prochain macOS Mac silicon only.

Apparemment, pas avant Mac OS 28 (ça laisse encore deux ans, ça devrait suffire pour tout mettre à jour).

[linus]

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.

Dans ces conditions, pourquoi ne peut on utiliser Rosetta 2 pour convertir une appli x86 en appli Apple Silicon distribuable telle que pour tous ? Pourquoi faut il cette conversion sur chaque machine qui utilise l'application en non pas une conversion une fois pour toute par le développeur avant distribution ?

[Paul Emploi]

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.

Dans ces conditions, pourquoi ne peut on utiliser Rosetta 2 pour convertir une appli x86 en appli Apple Silicon distribuable telle que pour tous ? Pourquoi faut il cette conversion sur chaque machine qui utilise l'application en non pas une conversion une fois pour toute par le développeur avant distribution ?

Le développeur n'existe peut-être déjà plus. L'éditeur ne supporte peut-être plus son application, en tout cas dans cette version. etc etc.

Du coté d'Apple cela leur aurait enlevé le contrôle sur ce point. Et Apple aime le contrôle.
On aurait aussi vu fleurir des logiciels "ARM" qui ne seraient que des transpilations par Rosetta 2 et bien moins performants pour certains (AVX sous x86 non traduits par exemple) que de véritables logiciels natifs...
Le dernier point aurait posé un problème d'image et de communication sévère.

Quand le M1 de base, l'entrée-de-gamme sur MacBook Air M1 ou Mac mini M1, cette "puce de smartphone" a totalement explosé les standards, changé la donne, et a contribué à faire exploser Intel en plein vol (qui se débrouillait très bien pour se saborder tout seul pourtant!).
J'ai hâte de vous parler du M1, peut-être trop performant à son époque, trop parfait, ce qui a coûté à Apple!

[linus]

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.

Dans ces conditions, pourquoi ne peut on utiliser Rosetta 2 pour convertir une appli x86 en appli Apple Silicon distribuable telle que pour tous ? Pourquoi faut il cette conversion sur chaque machine qui utilise l'application en non pas une conversion une fois pour toute par le développeur avant distribution ?

Le développeur n'existe peut-être déjà plus. L'éditeur ne supporte peut-être plus son application, en tout cas dans cette version. etc etc.

Du coté d'Apple cela leur aurait enlevé le contrôle sur ce point. Et Apple aime le contrôle.
On aurait aussi vu fleurir des logiciels "ARM" qui ne seraient que des transpilations par Rosetta 2 et bien moins performants pour certains (AVX sous x86 non traduits par exemple) que de véritables logiciels natifs...
Le dernier point aurait posé un problème d'image et de communication sévère.

Quand le M1 de base, l'entrée-de-gamme sur MacBook Air M1 ou Mac mini M1, cette "puce de smartphone" a totalement explosé les standards, changé la donne, et a contribué à faire exploser Intel en plein vol (qui se débrouillait très bien pour se saborder tout seul pourtant!).
J'ai hâte de vous parler du M1, peut-être trop performant à son époque, trop parfait, ce qui a coûté à Apple!

Donc, tu confirmes ce que je pensais, ce serait parfaitement possible mais ce n'est juste pas souhaitable pour Apple.
Dommage quand même.

[Celeri]

A l'époque où le M1 venait d'apparaître, j'ai essayé de comprendre où et comment macOS stocke les version "ARMisées" des binaires après leur recompilation, mais personne ne semblait s'être réellement étudié la chose... Je ne sais pas ce qu'il en est aujourd'hui, mais je me dis qu'avec un peu de bidouille, on devrait pouvoir utiliser cette recompilation pour faire des conversions en ARM "sauvages", ce qui serait utile pour quand Rosetta 2 ne sera plus supporté... J'espère que la communauté des hackers se penchera sur la question à l'approche de cette échéance !

[Benzebut]

Dans ces conditions, pourquoi ne peut on utiliser Rosetta 2 pour convertir une appli x86 en appli Apple Silicon distribuable telle que pour tous ? Pourquoi faut il cette conversion sur chaque machine qui utilise l'application en non pas une conversion une fois pour toute par le développeur avant distribution ?

Le fonctionnement de Rosetta 2 transpile le code pour Mac ARM pour être exécuté nativement. Il n'y aurait donc pas de création du binaire de l'application, mais des fichiers "caches" qui associés aux binaires Intel permettent à l'application sous macOS de fonctionner sous cette nouvelle architecture en toute transparence.

S'il y avait une véritable conversion, cela ferait 2 binaires de l'application qui seraient indépendants et pourraient tourner sous 2 architectures. Comme le fait actuellement macOS ou précédemment les applications au format Universel lors du passage sous Intel.

Et en fonction, cela rendrait de fait la faisabilité de conversions "sauvages" impossibles, puisque les fichiers "cache" seraient alors dépendant de la machine qui les a créé et non pas génériques pour une architecture, tout en dépendant de la disponibilité de Rosetta 2...

[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.

[Paul Emploi]

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.

Il manque pour moi clairement des solutions un peu plus universelles, tout en sachant que nombre d'anciennes interfaces ne sont plus supportées et qu'il faudrait les émuler ou les traduire.

Mais il n'y a techniquement aucune raison fondamentale pour que du code Mac PowerPC ne tourne pas sous Windows x86. Aucune.
Sauf que ça n'intéresse personne d'assurer l'interopérabilité sur la durée et au travers de différentes plateformes.

[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!

[Benzebut]

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!

Merci pour cette confirmation, je n'ai pas encore changé de machine pour tester cette nouvelle architecture ARM.
C'est donc comme Java pour la JVM et cela met fin au rêve de Celeri sur une pérennisation de ces "anciennes" applications macOS...

[jeandemi]

Probablement que toutes les librairies x86-64 vont disparaître de MacOS 27, ce qui empêcherait Rosetta 2 de fonctionner, donc ils l'enlèveront également

[Hebus]

Probablement que toutes les librairies x86-64 vont disparaître de MacOS 27, ce qui empêcherait Rosetta 2 de fonctionner, donc ils l'enlèveront également

Le changement opérerait sur macOS 28, excepté pour certains jeux non maintenus … d’après le doc de la WWDC

https://developer.apple.com/documentation/a...ion-environment

J’espère qu’ils maintiendront les morceau nécessaires aussi à Docker, même si professionnellement je ne serai pas obligé de mettre à jour mon OS pendant un bon bout de temps. Jusqu’à la retraite dans 3/4 ans