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

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

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