Le M1 annonce l’essor de RISC-V

« Le M1 aidera RISC-V en lançant un changement de paradigme, mais pas de la manière dont vous l’imaginez. »

Un article de suivi par l’ingénieur qui a écrit « Pourquoi la puce M1 est-elle si rapide ? ». Il anticipe l’avenir de RISC-V sous un angle intéressant.

Les facteurs de performance du M1 sont :

1. un grand nombre de décodeurs et l’exécution hors ordre (OoO)

2. plusieurs puces dédiées comme le GPU, le NPU, le DSP, etc.

Cet article développe plus en détail le point 2, à savoir le calcul hétérogène.

Ces puces dédiées peuvent porter plusieurs noms, mais ici elles sont toutes regroupées sous le terme de coprocessor (ou accelerator).

• Les coprocesseurs ne sont pas une tendance entièrement nouvelle.

• L’Amiga 1000, sorti en 1985, possédait déjà des coprocesseurs pour l’audio et le graphisme ; le GPU est aussi un coprocesseur.

Le TPU (Tensor Processing Unit) de Google est lui aussi un coprocesseur optimisé pour le machine learning.

[ Qu’est-ce qu’un coprocessor ? ]

• Contrairement au CPU, il ne peut pas fonctionner seul. Un ordinateur ne devient pas un ordinateur parce qu’on y ajoute seulement un coprocesseur ; c’est simplement un processeur spécialisé, conçu pour bien exécuter certaines tâches précises.

• Un exemple ancien est le 8087 Floating Point Unit (FPU) d’Intel. Le 8086 d’Intel savait bien effectuer les calculs entiers, mais beaucoup moins les opérations en virgule flottante.

• Il est possible d’émuler les opérations en virgule flottante à l’aide de calculs entiers, mais c’était lent. C’est comparable aux premiers microprocesseurs qui savaient seulement faire des additions et des soustractions, mais pas des multiplications, et devaient donc répéter plusieurs additions pour effectuer une multiplication.

• Autrement dit, « des calculs mathématiques complexes peuvent être traités en répétant des opérations simples ».

• Tous les coprocesseurs fonctionnent selon ce même principe. Le CPU peut faire ce que fait un coprocesseur ; il suffit de répéter des opérations simples.

• Si les premiers GPU étaient nécessaires, c’est parce que répéter le même calcul sur des millions de polygones ou de pixels prenait beaucoup trop de temps sur un CPU.

[ Comment les données entrent et sortent-elles d’un coprocesseur ? ]

• Tous les coprocesseurs, y compris le GPU, le FPU et le Neural Engine, tout comme la souris, le clavier ou l’écran, lisent et écrivent des données en accédant à certaines zones mémoire.

• Ces opérations sont prises en charge par les device drivers, donc les développeurs logiciels généralistes n’ont généralement pas à s’en occuper.

→ C’est notamment le rôle de contrôleurs DMA (Direct Memory Access).

• À l’époque de DOS, en C/C++, il était possible d’accéder directement à l’adresse mémoire vidéo avec un pointeur pour modifier des pixels.

• Les coprocesseurs fonctionnent de cette manière : le NPU, le GPU, le T1, etc. disposent chacun d’adresses leur permettant de communiquer, et cette communication peut être asynchrone.

• Le CPU écrit dans la mémoire la liste complète des commandes à envoyer au Neural Engine ou au GPU, puis leur indique l’adresse correspondante.

• Comme le CPU n’a pas besoin d’attendre que le coprocesseur traite ces commandes et ces données, cela rend les interruptions nécessaires.

[ Comment fonctionnent les interruptions ]

• Les cartes graphiques et réseau sont branchées dans le PC et disposent d’une ligne d’interruption assignée.

• Celle-ci fonctionne comme une ligne directement reliée au CPU : lorsqu’elle s’active, le CPU interrompt ce qu’il faisait pour traiter l’interruption.

• En pratique, il sauvegarde sa position courante et ses registres en mémoire afin de pouvoir reprendre plus tard.

• Ensuite, il cherche dans la table des interruptions le travail à exécuter. Cette table contient l’adresse du programme à lancer lorsqu’une interruption est déclenchée.

• Pour le programmeur, tout cela n’est pas visible ; cela ressemble plutôt à une fonction de callback enregistrée sur un événement précis. Le device driver gère ce traitement à bas niveau.

• Si l’auteur explique cela, c’est parce qu’il faut comprendre ce qui se passe lorsqu’on utilise un coprocesseur afin de savoir ce qu’implique réellement la communication avec lui.

• Avec les interruptions, beaucoup de choses se produisent en parallèle.

→ Pendant que le CPU est interrompu par la souris, l’application peut déjà récupérer une image depuis la carte réseau ; une fois la souris déplacée, le CPU obtient les nouvelles coordonnées, les envoie au GPU pour dessiner le curseur à sa nouvelle position, et pendant que le GPU dessine ce curseur, le CPU commence à traiter l’image récupérée sur le réseau.

• En utilisant ces interruptions, il est possible d’envoyer au Neural Engine du M1 des tâches complexes de machine learning pour identifier des visages via la webcam. Comme le Neural Engine traite les données image, l’ordinateur et le CPU peuvent continuer à effectuer d’autres tâches tout en restant réactifs pour l’utilisateur.

[ The Rise of RISC-V ]

• En 2010, le laboratoire de calcul parallèle de l’UC Berkeley a commencé à évoluer vers une direction où l’on utilise davantage de coprocesseurs.

• Il y voyait la fin de la loi de Moore, dans le sens où il ne devenait plus facile d’augmenter les performances simplement en poussant toujours plus loin les cœurs CPU généralistes.

→ D’où le besoin de coprocesseurs, c’est-à-dire de matériel spécialisé.

• La fréquence d’horloge ne peut pas être augmentée facilement en raison de la chaleur et de la consommation électrique.

→ Une approche consiste à utiliser davantage de décodeurs et l’exécution hors ordre (OoO).

→ Voir l’article « Pourquoi la puce M1 est-elle si rapide ? » https://fr.news.hada.io/topic?id=3315

[ Faut-il utiliser le budget transistor pour les cœurs CPU ou pour les coprocesseurs ? ]

• Passer à 128 cœurs ne rend pas forcément un système desktop plus efficace.

• Au début des années 1980, avec un budget de 20 000 transistors, il suffisait d’en consacrer 15 000 à la fabrication du CPU.

• Si un CPU accomplit 100 tâches différentes, et qu’un coprocesseur destiné à l’une de ces tâches nécessite 1 000 transistors, alors fabriquer un coprocesseur pour chacune de ces tâches demanderait 100 000 transistors, ce qui dépasserait le budget.

[ La stratégie change à mesure que le nombre de transistors augmente ]

• Les conceptions initiales devaient se concentrer sur le calcul généraliste, mais aujourd’hui on dispose d’un nombre immense de transistors, au point de ne plus toujours savoir quoi en faire.

• C’est pourquoi la conception de coprocesseurs devient un enjeu majeur. De nombreuses recherches sont en cours pour créer une grande variété de nouveaux coprocesseurs.

• Dans beaucoup de cas, cette recherche consiste à partir de zéro avec des accélérateurs très rudimentaires.

• Contrairement à un CPU, ils ne lisent ni ne traitent toutes les étapes d’instructions, et ne savent donc pas comment accéder à la mémoire ni comment organiser les données.

• Une solution simple consiste à utiliser un petit CPU comme contrôleur.

• Autrement dit, l’ensemble des coprocesseurs se compose d’un circuit accélérateur spécialisé, piloté par un CPU simple, et configuré pour accélérer une tâche spécifique.

→ Par exemple, des puces comme le Neural Engine ou le Tensor Processing Unit peuvent manipuler de grands registres capables de stocker des matrices.

[ RISC-V a été conçu sur mesure pour piloter les accelerators ]

• C’est précisément l’objectif pour lequel RISC-V a été conçu.

• Il dispose d’un jeu minimal de 40 à 50 instructions pour les tâches CPU générales.

→ Un CPU x86 possède environ 1 500 instructions.

• Au lieu d’un grand jeu d’instructions fixe, RISC-V a été conçu autour du concept d’extensions.

• Comme tous les coprocesseurs sont différents, RISC-V peut être configuré avec un jeu d’instructions cœur, auquel s’ajoutent des extensions adaptées aux besoins du coprocesseur.

C’est ce que cet article cherche à expliquer.

• Le M1 d’Apple va pousser l’ensemble de l’industrie vers un avenir dominé par les coprocesseurs.

• Et pour construire ces coprocesseurs, « RISC-V sera une pièce importante du puzzle ».

[ Pourquoi créer un coprocessor avec RISC-V est intéressant ]

• Concevoir une puce est une tâche complexe et coûteuse.

• Construire des outils pour la vérification de puces, exécuter des programmes de test, faire du diagnostic et bien d’autres choses demande énormément d’efforts.

• C’est d’ailleurs une partie de la valeur actuelle d’ARM : il existe un vaste écosystème qui permet de valider et de tester les conceptions.

• C’est pourquoi disposer de son propre jeu d’instructions n’est pas une bonne idée.

• RISC-V fournit un standard qui permet à plusieurs entreprises de développer des outils ; un écosystème se crée, et plusieurs acteurs peuvent en partager la charge.

• Pourquoi ne pas utiliser ARM, qui existe déjà ? Parce qu’ARM a été conçu comme CPU généraliste et possède un grand jeu d’instructions fixe.

• Sous la pression des demandes clients et de la concurrence de RISC-V, ARM a lui aussi présenté en 2019 un jeu d’instructions extensible.

• Mais le problème demeure : ARM n’a pas été conçu pour cela dès le départ.

→ Toute la toolchain ARM part du principe qu’un grand jeu d’instructions ARM est implémenté.

→ Or les coprocesseurs ne veulent pas forcément, ni n’ont besoin, d’un grand jeu d’instructions.

→ Ils veulent un écosystème d’outils construit autour de l’idée d’un jeu d’instructions de base minimal et fixe, enrichi d’extensions.

• On peut en voir l’intérêt à travers l’usage de RISC-V chez Nvidia.

→ Les gros GPU ont besoin d’une sorte de CPU généraliste pour servir de contrôleur.

→ Nvidia a créé et utilisé une puce appelée FALCON : FAst Logic CONtroller.

→ Faible coût, haute efficacité.

• Grâce à son jeu d’instructions petit et simple, RISC-V surpasse tous ses concurrents, y compris ARM, dans ce rôle.

• En choisissant RISC-V, Nvidia a pu concevoir des puces plus petites avec une consommation minimale.

• Grâce au mécanisme d’extensions, il est possible d’ajouter uniquement les instructions nécessaires à la tâche visée.

[ ARM deviendra le nouvel x86 ]

• Ironiquement, nous pourrions voir un avenir où Mac et PC fonctionneront sur ARM.

• Mais autour de ce cœur, le matériel custom sera occupé par des coprocesseurs dominés par RISC-V.

• À mesure que les coprocesseurs se généralisent, il y aura plus de puces RISC-V que de puces ARM sur les SoC.

• L’avenir ne sera pas ARM or RISC-V, mais ARM and RISC-V.

[ ARM commandera une armée de coprocesseurs RISC-V ]

• Le processeur ARM généraliste restera au centre, entouré d’une armée de coprocesseurs RISC-V chargés des graphismes, du chiffrement, de la compression vidéo, du machine learning et du traitement du signal.

• Le professeur David Patterson de l’UC Berkeley et son équipe ont vu venir cet avenir et ont ajusté RISC-V pour qu’il y corresponde bien.

• Toutes sortes de matériels spécialisés et de microcontrôleurs montrent un grand intérêt pour RISC-V, et nombre de domaines aujourd’hui dominés par ARM pourraient passer à RISC-V.

[ Ne pourrait-on pas utiliser RISC-V comme CPU principal ? ]

• Beaucoup se demandent s’il ne faudrait pas remplacer complètement ARM par RISC-V.

• Certains affirment que le jeu d’instructions extrêmement simple de RISC-V ne pourrait pas offrir les hautes performances d’ARM et de x86.

• Pourtant, RISC-V peut tout à fait servir de processeur principal, et les performances ne sont pas le problème.

→ Il faut simplement quelqu’un pour construire un RISC-V hautes performances, comme cela a été fait pour ARM.

→ En d’autres termes, c’est possible, mais c’est une question de momentum. macOS et Windows tournent déjà sur ARM.

→ À court terme, ni Microsoft ni Apple ne feront probablement l’effort d’une nouvelle transition matérielle.

[functor]

C’est intéressant. Merci pour ce bon résumé.

On verra donc bientôt arriver le jour où, même à l’école, les cours d’architecture seront enseignés en se basant sur ARM ou RISC-V plutôt que sur x86 ou amd64...

[kunggom]

Il me semble qu’un ancien ingénieur d’ARM avait déjà publié ici une critique de RISC-V.

https://fr.news.hada.io/topic?id=3137

Si l’on suit ce qui est dit ci-dessus, alors le fait que la diversité des puces adoptant RISC-V augmente serait intentionnel.

[jwstyle]

Cela devient de plus en plus passionnant.

Je me demande comment Intel et AMD vont réagir.

[cloverhearts]

Il me semble savoir que la Chine mise presque à fond sur RISC-V... Franchement, je n'arrive même pas à imaginer ce que l'avenir nous réserve.

[xguru]

J’y ai pensé aussi, à la Chine. Si Huawei, qui continue de subir la pression américaine, prenait les devants et essayait d’en faire un CPU principal, qu’est-ce que ça donnerait ? haha

[kbumsik]

Comme Huawei ne peut utiliser ni ARM ni TSMC, on peut pratiquement considérer que le développement même de CPU hautes performances est de toute façon condamné. À la limite, peut-être pour ses propres équipements réseau, qui exigent moins de performances.

Mais comme beaucoup d'autres entreprises utilisent RISC-V, il semble probable que des résultats viennent de leur côté.

[xguru]

Ah, je n’avais pas pensé au fait que TSMC lui-même soit bloqué. À moins que SMIC ne parvienne à développer un procédé allant au-delà du 7 nm jusqu’au 5 nm, ça semble compliqué.

[xguru]

Cette personne écrit vraiment très bien. J’ai aussi lu ça avec beaucoup de plaisir.

Il y avait déjà beaucoup de prévisions selon lesquelles RISC-V pourrait devenir une autre alternative,

mais je n’avais jamais envisagé les choses sous l’angle où, de cette manière, il pourrait devenir la meilleure puce possible pour des coprocesseurs.