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 ?

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