Pourquoi la puce M1 d’Apple est-elle si rapide ?
(erik-engheim.medium.com)- La M1 n’est pas un simple CPU, mais un système complet regroupant plusieurs puces dans un grand boîtier en silicium. Le CPU n’en est qu’un composant parmi d’autres.
→ Un SoC (System on a Chip) qui réunit CPU, GPU, mémoire, contrôleur d’E/S, etc.
- Au lieu d’intégrer beaucoup de cœurs généralistes, elle embarque des puces spécialisées pour des tâches précises.
→ CPU : exécute l’OS et les applications
→ GPU : gère le rendu graphique, l’interface des applications, les jeux 2D/3D, etc.
→ ISP (Image Processing Unit) : accélère le traitement d’image
→ DSP (Digital Signal Processor) : exécute des opérations plus intensives en calcul que le CPU, comme la décompression de fichiers audio
→ NPU (Neural Processing Unit) : accélère le machine learning, la reconnaissance vocale, le traitement photo, etc.
→ Encodeur/décodeur vidéo : traite les fichiers et formats vidéo avec une faible consommation
→ Secure Enclave : chiffrement, authentification, sécurité
→ UMA (Unified Memory Architecture) : permet au CPU, au GPU et aux autres cœurs d’échanger rapidement des informations
C’est pour cela que ces puces excellent en retouche d’image, en montage vidéo et dans l’encodage de gros volumes vidéo.
- Qu’a donc de spécial la Unified Memory Architecture (UMA) ?
→ Les anciennes puces intégrant CPU et GPU étaient lentes.
Les deux utilisaient des zones mémoire distinctes, chacune à leur manière.
Et comme les GPU chauffent beaucoup, les meilleures performances venaient de grosses cartes dotées de grands ventilateurs.
Mais dans ce cas, il faut copier énormément de données d’un composant à l’autre, ce qui nécessite un bus comme le PCIe.
→ La Unified Memory n’alloue pas de mémoire séparée au CPU et au GPU : ils utilisent la même.
Contrairement à la mémoire partagée classique, CPU et GPU peuvent y accéder simultanément, et un simple échange d’informations de localisation suffit, sans copie des données.
- Si cette approche SoC est si bonne, pourquoi les autres fabricants ne la suivent-ils pas ?
→ En réalité, ils le font déjà. AMD a commencé à produire des APU mettant CPU et GPU sur le même die silicium.
→ Mais c’est difficile à mettre en œuvre, car un SoC revient à intégrer l’ordinateur entier sur une seule puce, une approche davantage adaptée à des fabricants comme HP ou Dell.
→ Le modèle économique d’Intel et d’AMD repose sur des CPU génériques que les gens installent sur une carte mère de PC.
Le nouveau marché des SoC ne consiste plus à assembler des produits physiques de fournisseurs différents, mais à assembler de la propriété intellectuelle (IP, Intellectual Property).
→ Intel, AMD ou Nvidia peuvent-ils vraiment concéder leur IP sous licence à Dell ou HP ?
→ Bien sûr, Intel et AMD pourraient vendre des SoC complets, mais cela créerait potentiellement des conflits d’intérêts entre le fabricant de CPU, l’assembleur PC et Microsoft sur ce qu’il faut intégrer.
→ Pour Apple, c’est un sujet simple : l’entreprise fabrique tout elle-même. « They control the whole widget ».
- Le défi fondamental pour rendre un CPU rapide
→ Le Firestorm, le cœur CPU généraliste rapide de la M1, est vraiment très rapide. C’est précisément ce qui distingue cette génération des anciens ARM, historiquement plus lents face à AMD et Intel.
→ Le Firestorm dépasse la plupart des cœurs Intel et AMD Ryzen en vitesse, ce qui paraît contraire au bon sens.
→ Quelle est la stratégie pour construire un CPU rapide ?
-
Exécuter chaque instruction plus vite, séquentiellement
-
Exécuter plusieurs instructions en parallèle
Dans les années 80, c’était simple : il suffisait d’augmenter la fréquence d’horloge pour exécuter les instructions plus rapidement.
Un ordinateur fait quelque chose à chaque cycle d’horloge, et ce « quelque chose » est minuscule ; une seule instruction peut donc nécessiter plusieurs cycles.
Mais aujourd’hui, augmenter la fréquence d’horloge a ses limites.
« La fin de la loi de Moore »
Il est donc désormais essentiel d’exécuter autant d’instructions que possible en parallèle.
- Multi-core or Out-of-Order processors?
→ Il existe deux approches pour l’exécution parallèle.
- Ajouter davantage de cœurs CPU (du point de vue du développeur, cela revient à ajouter des threads)
En théorie, les cœurs d’un processeur peuvent exécuter plusieurs threads (threads logiciels).
Mais cela repose sur une exécution alternée entre threads, utile surtout lorsqu’on attend des E/S ou du réseau.
Les threads matériels peuvent accélérer les traitements, mais le développeur doit écrire du code pour en tirer parti.
Ce modèle convient bien aux serveurs et au cloud.
C’est pourquoi des entreprises comme Ampere conçoivent des CPU ARM pour le cloud comme l’Altra Max à 128 cœurs.
Apple fait exactement l’inverse : c’est une entreprise qui construit des appareils pour un utilisateur unique.
La plupart des logiciels desktop ne sont pas conçus pour exploiter un grand nombre de cœurs.
Un jeu peut gagner en performances avec 8 cœurs, mais 128 cœurs seraient du gaspillage.
Il faut donc plutôt un petit nombre de cœurs très puissants.
- L’exécution hors ordre (Out-of-Order Execution, OoO) permet aussi d’exécuter plus d’instructions en parallèle, mais sans avoir besoin de l’exposer explicitement comme avec le multithreading.
Du point de vue du développeur, cela donne simplement l’impression que chaque cœur est plus rapide.
Aller chercher des données à un emplacement mémoire précis est lent.
Mais qu’on récupère 1 octet ou 128 octets, la différence de latence est nulle.
Les données transitent sur un bus, et plus ce bus est large, plus on peut lire d’octets simultanément.
Lors de l’exécution, le CPU traite plusieurs blocs d’instructions à la fois, même si celles-ci ont été écrites pour être exécutées séquentiellement.
Les microprocesseurs modernes pratiquent l’exécution Out-of-Order.
Autrement dit, ils analysent plusieurs instructions pour déterminer si elles dépendent les unes des autres.
01: mul r1, r2, r3 // r1 ← r2 × r3
02: add r4, r1, 5 // r4 ← r1 + 5
03: add r6, r2, 1 // r6 ← r2 + 1
Dans cet exemple, les instructions 1 et 2 sont dépendantes, mais la 3 n’a aucun lien avec elles.
Un processeur Out-of-Order peut donc exécuter l’instruction 3 en parallèle.
En pratique, un CPU peut analyser les dépendances non pas entre une ou deux instructions, mais entre des centaines.
Le CPU relie les instructions sous forme de graphe de nœuds, puis l’analyse pour déterminer lesquelles peuvent être exécutées en parallèle et lesquelles doivent attendre un résultat préalable.
Si les cœurs Firestorm de la M1 sont si rapides, c’est grâce à une exécution Out-of-Order exceptionnelle.
Ils semblent même supérieurs à tout ce que proposent les autres acteurs du marché grand public, y compris Intel et AMD.
- Pourquoi l’exécution Out-of-Order d’AMD et d’Intel est-elle plus lente que celle de la M1 ?
→ Ce dont on parlait plus haut correspond en pratique au ROB (Reorder Buffer), qui n’est pas du code machine ordinaire (celui que le CPU lit en mémoire pour l’exécuter).
Ces instructions relèvent de l’Instruction Set Architecture (ISA) du CPU, autrement dit ce qu’on appelle x86, ARM ou PowerPC.
→ En interne, le CPU exécute en réalité un tout autre jeu d’instructions, inconnu du programmeur : les micro-operations (micro-instructions, micro-ops ou μops), et le ROB est rempli de ces micro-ops.
→ On peut considérer les instructions ARM/x86 comme une API publique, et les micro-ops comme une API privée.
→ En CISC, les instructions étant grosses et complexes, l’usage de micro-ops est indispensable ; en RISC, on peut choisir de les utiliser ou non.
(Par exemple, les petits CPU ARM peuvent s’en passer. Cela ne signifie pas qu’ils sont incapables de faire de l’OoO.)
→ Pourquoi est-ce important ? Parce que « la vitesse dépend de la rapidité et de la quantité avec lesquelles on peut remplir le ROB ».
→ Plus on le remplit vite, plus on a d’occasions d’exécuter un grand nombre d’instructions en parallèle, ce qui améliore les performances.
→ Le code machine est découpé en micro-ops par les décodeurs.
→ Les cœurs Intel et AMD disposent de 4 décodeurs,
alors qu’Apple en a 8, un nombre « délirant », et un ROB trois fois plus grand, capable de contenir environ trois fois plus d’instructions.
- Alors pourquoi Intel et AMD n’ajoutent-ils pas plus de décodeurs d’instructions ?
→ C’est là que commence la revanche du RISC. Le fait que le cœur Firestorm de la M1 repose sur l’architecture ARM RISC est crucial.
→ Les instructions x86 ont une longueur de 1 à 15 octets, alors que celles du RISC ont une taille fixe.
→ Si toutes les instructions ont la même longueur, il suffit de découper le flux et de l’envoyer vers 8 décodeurs différents.
→ Mais avec le x86, on ne sait pas automatiquement où commence l’instruction suivante, donc il faut analyser chaque instruction une par une.
→ Intel et AMD traitent ce problème en force brute en essayant de décoder à chaque début possible d’instruction,
ce qui implique de jeter en permanence les mauvaises suppositions et les erreurs.
C’est pourquoi il est difficile d’ajouter davantage de décodeurs, alors que pour Apple c’est beaucoup plus simple.
→ C’est fondamentalement ce qui permet de traiter environ deux fois plus d’instructions à fréquence égale qu’un CPU AMD ou Intel.
→ En pratique, le x86 n’utilise pas souvent les instructions CISC les plus complexes et se comporte souvent comme du RISC avec des instructions courtes, mais il faut tout de même pouvoir gérer ces instructions de 15 octets, ce qui entretient la complexité.
- Mais alors, le cœur Zen3 d’AMD reste quand même plus rapide, non ?
→ En benchmark, Zen3 est effectivement plus rapide que Firestorm, mais Zen3 tourne à 5 GHz alors que Firestorm est à 3,2 GHz.
→ Si Apple n’augmente pas davantage la fréquence, c’est parce que la puce chaufferait trop.
→ Fondamentalement, le cœur Firestorm est supérieur à Zen3.
→ Zen3 peut consommer plus d’énergie et produire plus de chaleur pour viser le jeu, mais « Apple a choisi de ne pas entrer dans cette logique ».
→ Si Apple voulait plus de performances, l’entreprise ajouterait davantage de cœurs. Elle pourrait ainsi obtenir de meilleures performances avec moins d’énergie.
- Avenir
→ AMD et Intel se sont en quelque sorte eux-mêmes coincés sur deux plans.
-
Ils n’ont pas de modèle économique qui pousse naturellement vers le calcul hétérogène et la conception de SoC.
-
L’héritage des instructions x86 CISC complexes rend plus difficile l’amélioration des performances de l’OoO.
→ Bien sûr, la partie n’est pas terminée. Ils peuvent encore monter en fréquence, améliorer le refroidissement, utiliser plus de cœurs, etc.
→ Intel est dans une situation encore plus difficile. L’entreprise est déjà derrière Firestorm sur la vitesse des cœurs, et le GPU intégré à ses SoC est médiocre.
→ Avoir beaucoup de cœurs est naturellement un avantage sur serveur, mais Amazon et Ampere attaquent avec des processeurs à 128 cœurs. Intel et AMD doivent donc se battre sur les deux fronts.
→ Heureusement pour AMD et Intel, Apple, à la différence d’eux, ne vend pas ses puces sur le marché.
→ Pas immédiatement, sans doute, mais les utilisateurs de PC migreront lentement vers Apple, et Apple prendra une part plus importante du marché du PC.
17 commentaires
Vous écrivez vraiment très bien.
Merci d’avoir si bien résumé les choses de manière très facile à comprendre. Le top !
Merci pour ce contenu de qualité.
Merci !!
Je voulais m’acheter un appareil avec puce M1, mais apparemment j’aurais plutôt dû acheter des actions..
Merci pour ce bon article !
Je pense aussi que l'action Apple a une forte valeur future.
J'ai l'impression qu'un jour, l'Apple Car finira vraiment par voir le jour.
Le weak memory model devient de plus en plus important... Apple est vraiment en train de devenir une entreprise fermée capable de tout fabriquer elle-même, de la puce à l’assemblage, au hardware, à l’OS et aux apps, comme Jobs en rêvait.
Moi aussi, je pense que mon prochain appareil sera un Mac mini M1 ou un MacBook Air.
Moi aussi, je suis passé d’un MacBook Pro 2015 au M1… On me dit qu’il arrivera d’ici la fin de l’année, sinon au début de l’année prochaine !
Je viens de vérifier, c’est sorti en Corée !
Waouh ! Guru, vous êtes vraiment le meilleur !!
Merci ;)
Il y a aussi dans cet article un passage où l’auteur compare RISC et CISC, et je le recommande vraiment à fond. Il explique de façon très fluide pourquoi on en est arrivé à avoir ce type d’architecture d’instructions.
J’ai l’impression que c’est quelqu’un qui écrit fondamentalement très bien. Cet article est assez long lui aussi, mais il se lit très bien.
Waouh, merci pour cet excellent contenu.
Merci !
J’ai l’impression de reprendre un cours d’architecture des ordinateurs haha
Au final, Apple a une structure qui lui permet de continuer à toujours mieux faire ce qu’elle sait faire de mieux.
Qu’est-ce qu’Intel et AMD vont bien pouvoir faire maintenant…
Dans l’épisode 16 du podcast GeekNews publié aujourd’hui, on a brièvement présenté l’astuce de Memory-Order de la puce M1, mais cet article est encore différent et beaucoup plus détaillé.
On dirait bien qu’on en reparlera encore dans le podcast de la semaine prochaine ^^;