Les CPU des Mac : ARM (bonus), Réactions à la publication du 01/01/2024

[Paul Emploi]

Pour commencer l'année 2024 du bon pied, je voudrais mettre en avant 3 caractéristiques des architectures ARM 32 bits, qui ont fait sa réussite et il y a du génie là-dedans.

Bien sûr chaque grande architecture a de grandes qualités, ça n'est certainement pas pour minimiser celles des concurrents, mais juste mettre en exergue ce qui a différencié ARM.

Exécution conditionnelle

On avait vu que les branchements conditionnels pris posaient des problèmes d'optimisation à cette époque en l'absence de cache de branchement et d'exécution spéculative, l'instruction suivant immédiatement le branchement étant déjà lue depuis la mémoire, amenant dans une hypothétique CPU à 1 cycle par instruction au moins 2 cycles utilisés en cas de saut, 1 cycle sinon.
Dans la pratique, on était plutôt à une perte de quelques cycles, 3 à 7 en fonction de la longueur du pipeline!

L'idée de génie fut d'offrir une exécution conditionnelle des instructions, permettant alors de se passer de branchement et de saut quand 1 à 3 instructions se suivent sans modifier le registre de condition.
Dans ce cadre-là, au lieu de sauter et sans avoir d'instruction de saut conditionnel, la CPU passe à 1 instruction par cycle devant celles-ci et ne les exécute pas, avec un avantage énorme sur du code simple.

En revanche, les instructions font 32 bits, ce qui augmente énormément la taille du code à comparer à environ 18 bits en moyenne sur du 386, à une époque où contrairement à aujourd'hui c'est celui-ci qui faisait l'essentiel des logiciels et non des ressources obèses.

Encodage d'instruction Thumb

32 bits par instruction c'était donc énorme, quasiment deux fois plus important que pour du x86, et l'avenir d'ARM se jouait sur la mobilité dont déjà des téléphones qu'on a après appelé feature-phone, des téléphones cellulaires avec des fonctionnalités avancées.

Sous la pression de la demande des fabricants de ces feature-phone, l'équipe d'ARM a eu une idée de génie!
Après avoir réduit le nombre d'instruction de leur architecture de type Berkley, ils allaient réduire l'encodage de ces mêmes instructions, écartant ainsi les encodages avec des paramètres peu ou pas utilisés pour ne garder que les plus courant, et réussir à diviser par quasiment deux l'espace occupé par les logiciels.

Thumb n'est pas un "jeu d'instruction 16 bits", c'est bien quasiment le même jeu d'instruction travaillant en 32 bits, mais c'est l'encodage lui-même qui a été réduit à 16 bits, offrant ainsi une densité compétitive avec le x86, limitant les accès mémoires ainsi que la quantité de ROM nécessaire sur les produits l'intégrant initialement.

Mode et Sous-ensemble d'instruction Jazelle DBX

Java était alors un hot spot (sic) pour les appareils mobiles, incluant les feature-phone et ce qui deviendra les prémices de nos smartphone.
Faute à la fois de grosse capacité de traitement, mais aussi d'espace mémoire, ces appareils ne pouvaient vraiment implémenter efficacement ni une compilation complète ni même du JIT optimisé, chaque cycle étant compté, chaque octet aussi.

Il fallait quand-même offrir de bonnes performances pour du code Java et plus spécifiquement sa plateforme J2ME. Et non J2EE comme on a pu le lire.

ARM a encore fait un choix original: offrir un mode alternatif où le bytecode Java est à 95% exécuté directement par la CPU, avec donc 5% des instructions exécutées via une émulation logicielle, le tout ne nécessitant que très peu de mémoire (ROM en fait) en offrant des performances suffisantes même si non-optimales.

ARMv8 64 bits: plus proche du x86!

ARM a pris le chemin du 64 bits bien après les concepteurs de CPU pour micro-ordinateur individuel classiques et surtout de serveurs, car les plateformes mobiles en avait bien moins besoin étant à l'époque très loin des limites de gestion mémoire et surtout focalisées sur l'économie d'énergie et l'autonomie. Chaque transistor a un coût, et surtout un coût énergétique sur un appareil mobile.

Cela lui a permis de réviser son architecture pour le 64 bits, et en fait de repartir d'une feuille blanche tant pour les fonctionnalités que le jeu d'instruction et son encodage.
Au contraire du x86, chez ARM il n'y a pour ainsi dire aucun point commun entre ses CPU 32 bits et 64 bits à part le logo de la société!

Finito l'exécution conditionnelle, à la trappe Thumb puis Thumb-2, plus question de Jazelle et ajout d'instructions mémoires apportant des garanties d'ordonnancement et d'atomicité dans un sens ou l'autre, LDAR et STLR.
Aucune compatibilité binaire, pas plus de compatibilité sur le code-source en langage d'assemblage, ARM a fait table-rase du passé pour le 64 bits.

Ce passage au 64 bits montre que cette société, ses chercheurs et ingénieurs sont toujours pragmatiques, à la recherche de la bonne solution dans un contexte qui a changé du tout au tout.
ARM en 64 bits vise différents marché maintenant que le marché des smartphone est bien verrouillé, de nos micro-ordinateurs aux stations de travail jusqu'aux serveurs dans le cloud!

Lien vers le billet original

[Hebus]

Merci pour ces informations

En ce qui concerne le 64 bits, quelle a été la motivation d’Apple pour y passer rapidement ? L’enclave sécurisée ?

[Paul Emploi]

On ne peux que spéculer.

L'effet d'annonce a été très important dans le monde des fabricants de SoC pour appareils mobiles, le CEO de Qualcomm allant même jusqu'à déclarer que le 64 bits était inutile, pour sortir le leur un an plus tard.

Les Mac ARM étaient probablement déjà dans les tuyaux, au moins comme un potentiel, et le A7 présenté comme "Desktop class" ce qui avait été validé par AnandTech.
Le passage aux Mac Intel avait pris au moins 6 ans entre les premiers portages et l'arrivée des produits commerciaux, et on est en 2014 avec le A7 soit 6 ans avant l'arrivée des Mac ARM!

Il y a aussi la durée de support logiciel qui compte, environ 7 ans, d'où l'intérêt de sortir du 32 bits le plus tôt possible pour éviter de devoir supporter iOS en 32 bits trop longtemps.
Apple a d'ailleurs rapidement fermé le robinet aux versions d'iOS 32 bits, avec iOS 11 uniquement 64 bits au bout de 5 ans, même si iOS 10 a été supporté jusqu'en mi-2019.
En parallèle Apple s'était aussi débarrassé du 32 bits sous OS X.
Étant alors passé de 2 plateformes x86 et ARM, dans 2 variantes 32 bits et 64 bits, à 2 plateformes 64 bits.

Finalement, ARM 64 bits n'a rien de commun avec ARM 32 bits et probablement avait-il été jugé que justement ce 32 bits n'aurait pas les mêmes capacités d'évolution en terme de performances, non car 32 bits mais à cause des particularités de son jeu d'instruction dont l'exécution conditionnelle devenus inutiles et même un frein.
L'exécution conditionnelle n'est intéressante qu'avec une poignée d'instructions, ce qui est de moins en moins le cas avec les langages de très haut-niveau dont Swift, en l'absence de cache de branchement et d'exécution spéculative.

Peut-être aussi un ensemble de ces points?

[Benzebut]

Il y a aussi la durée de support logiciel qui compte, environ 7 ans, d'où l'intérêt de sortir du 32 bits le plus tôt possible pour éviter de devoir supporter iOS en 32 bits trop longtemps.
Apple a d'ailleurs rapidement fermé le robinet aux versions d'iOS 32 bits, avec iOS 11 uniquement 64 bits au bout de 5 ans, même si iOS 10 a été supporté jusqu'en mi-2019.

Plutôt avoir une version iOS en 64 bits le plus tôt possible dans la construction de la phrase, non ?

[malloc]

Aucune compatibilité binaire, pas plus de compatibilité sur le code-source, ARM a fait table-rase du passé pour le 64 bits.

Merci pour l'article, c'est intéressant. En revanche la portabilité de code source durant cette transition a été remarquable (PPC->Intel anyone?)

[Paul Emploi]

Oups la bourde, c'est rectifié car comme certains l'auront compris il s'agissait de compatibilité avec le code source en langage d'assemblage.

La compatibilité des logiciels en langage dits de haut-niveau en espace utilisateur est bien meilleure évidemment, c'est une partie de leur rôle.