Je veux un bon ordinateur parallèle

• Les GPU sont 10 à 100 fois plus puissants que les CPU, mais ils ont du mal à traiter les charges dynamiques et manquent d’outils de programmation parallèle, ce qui fait qu’ils n’exploitent pas pleinement leurs performances sur les tâches générales
• Par le passé, des architectures d’ordinateurs parallèles comme Connection Machine, Cell ou Larrabee ont existé, mais ont échoué à cause notamment de la complexité de leur modèle de programmation
• Les GPU modernes sont difficiles à optimiser en raison des problèmes de gestion mémoire et d’un modèle d’exécution complexe, et ils ont besoin d’une structure efficace de transfert de données fondée sur des files d’attente
• De nouvelles architectures comme les accélérateurs IA et les ensembles de cœurs parallèles pourraient permettre de dépasser les limites des GPU
• L’évolution des ordinateurs parallèles reste inachevée, et nécessite un modèle d’exécution simple et efficace ainsi que de meilleurs outils de programmation

La puissance et les limites des GPU

• Les GPU sont environ 10 à 100 fois plus puissants que les CPU (selon le type de tâche)
• Cette puissance est bien exploitée dans le rendu graphique en temps réel et le machine learning
• En revanche, les performances des GPU restent sous-exploitées sur les tâches générales

Les causes des limites des GPU

• Un modèle d’exécution insuffisant
  • Les GPU excellent sur de grandes masses de données prévisibles (par ex. la multiplication de matrices denses), mais leurs performances chutent sur les charges dynamiques
• Des langages et outils insuffisants
  • Programmer des ordinateurs parallèles est en soi très difficile

Une complexité croissante

• Les GPU récents voient leur complexité augmenter rapidement
• De nouvelles fonctionnalités comme les mesh shaders et les work graphs ont été introduites, mais certaines tâches de base ne sont toujours pas prises en charge

Le problème complexe de l’efficacité mémoire sur GPU

• L’auteur développe actuellement Vello, un moteur avancé de rendu graphique vectoriel 2D
  • Le CPU charge une description de scène (au format SVG) → un compute shader la traite puis génère l’image
• Problème : la difficulté de la gestion mémoire
  • Il est difficile de prédire la taille des buffers nécessaires pour stocker les résultats intermédiaires
  • En cas de dépassement de buffer, une lecture du GPU vers le CPU entraîne une baisse de performances

Proposition de solution

• Améliorer le GPU pour qu’il transmette les résultats en interne via une file d’attente (queue)
  • Un modèle proposé dans l’article GRAMPS de 2009
  • Une approche similaire a aussi été tentée dans le projet Brook

Anciens designs d’ordinateurs parallèles

• Connection Machine (1985)

  • Un ordinateur parallèle dont 64k processeurs étaient reliés par un réseau hypercube
  • Chaque processeur avait de faibles performances, mais l’ensemble permettait du parallélisme à grande échelle
  • A fortement contribué à la recherche sur les algorithmes parallèles

• Cell (2006, PS3)

  • Un ordinateur parallèle intégré à la PS3 (environ 87,4 millions d’unités expédiées)
  • 8 cœurs parallèles pouvaient exécuter des calculs indépendamment
  • L’échec est dû à la complexité du modèle de programmation

• Larrabee (2008)

  • Développé comme un ordinateur parallèle basé sur x86
  • Raisons de l’échec : consommation électrique et manque de support logiciel
  • A ensuite donné naissance à Xeon Phi et aux instructions AVX-512

Des charges de travail qui évoluent

• Même dans les jeux, la part des charges de calcul augmente
  • Dans Starfield, environ 50 % du temps total de traitement est consacré au calcul
  • Le moteur de rendu Nanite traite aussi la rasterisation de petits triangles par calcul

Les orientations futures

• 1. Étendre les ensembles de cœurs (retour de Cell)

  • Les CPU haut de gamme modernes intègrent plus de 100 milliards de transistors
  • Il devient possible de fabriquer des puces contenant des centaines ou des milliers de cœurs RISC simples et sobres en énergie
  • Les accélérateurs IA adoptent déjà une architecture similaire

• 2. Exécuter des commandes Vulkan sur le GPU

  • Permettre au GPU d’exécuter directement des commandes Vulkan
  • Cela est déjà implémenté de manière limitée dans certaines extensions Vulkan

• 3. Work Graph

  • Le programme est composé de nœuds (kernels) et d’arêtes (queues)
  • L’exécution est parallèle, mais avec les limites suivantes
    • Les opérations de jointure (join) sont difficiles
    • L’ordre de tri des éléments n’est pas garanti
    • Les éléments de taille variable ne sont pas pris en charge

• 4. Une évolution vers la fusion avec le CPU

  • Les designs de CPU haute performance pourraient évoluer pour mieux s’optimiser pour le calcul parallèle
  • Les performances du calcul parallèle et du SIMD (single instruction, multiple data) continuent de progresser

• 5. Le matériel est peut-être déjà prêt

  • Certains GPU incluent déjà des processeurs de commandes capables d’exécuter du code utilisateur
  • Si ces processeurs de commandes s’ouvrent complètement, des gains de performances sont possibles

Le problème de la complexité

• L’architecture des GPU est excessivement complexe
  • S’y mélangent ordinateur parallèle, matériel spécialisé et structure de traitement des commandes
  • Avec des problèmes de compatibilité entre différentes API et différents pilotes
• À l’inverse, les CPU continuent d’améliorer leurs performances à partir d’un jeu d’instructions simple

Conclusion

• L’évolution des ordinateurs parallèles reste inachevée
• Pour que les GPU s’optimisent pour des tâches générales au-delà du graphisme et de l’IA, il faut
  • un modèle d’exécution simple
  • une programmation plus facile
  • une faible consommation électrique
• Il deviendra possible d’exploiter pleinement la puissance des ordinateurs parallèles dans des travaux comme les moteurs de rendu 2D avancés tels que Vello
• Une nouvelle architecture d’ordinateur parallèle est nécessaire pour dépasser les limites de performance des GPU

[GN⁺]

Commentaires sur Hacker News

• « Je pense que deux facteurs principaux freinent cela »

  • tendance à emballer les opinions dans un vernis scientifique
  • l’expérience de travail sur le processeur Cell demandait beaucoup de microgestion
  • les systèmes modernes sont conçus en tenant compte de la protection mémoire, de l’isolation et de la stabilité
  • faire écrire du code sur un Amiga donnerait une nouvelle appréciation

• Le modèle de programmation est inefficace en 2025

  • il faut compiler le code source / bytecode des shaders à l’exécution
  • manipuler les structures de données entre CPU et GPU est difficile sur NUMA / discret
  • une synchronisation de l’accès aux données est nécessaire entre CPU-GPU et entre tâches GPU
  • il faut gérer des API déroutantes à cause d’un matériel non standardisé
  • il faut gérer les combinaisons de configurations variées

• expérience de travail dans une entreprise qui « mettait des centaines de petits CPU sur une seule puce »

  • le modèle de programmation est si étrange qu’il échouera
  • la prochaine génération sera des GPU avec des fonctionnalités supplémentaires, pas une nouvelle architecture

• Le GPU est 10 à 100 fois plus puissant que le CPU

  • beaucoup de tâches n’ont pas besoin de plus de performances
  • les interfaces graphiques réagissent aux entrées utilisateur depuis plus de 20 ans
  • il faut simplifier la programmation GPU

• avis sur la construction d’un superordinateur avec des M4 Mac mini

  • rétro-ingénierie du jeu d’instructions du GPU et du Neural Engine de l’Apple M3 Ultra
  • peut effectuer plus de 50 billions d’opérations par seconde

• problèmes des ordinateurs parallèles

  • beaucoup de gens doivent adopter les machines à des fins de développement
  • porter du code du CPU vers le GPU est un gros travail
  • AMD et d’autres entreprises explorent l’idée de rapprocher davantage les GPU des CPU

• on ne voit pas clairement pourquoi un moteur de rendu 2D a besoin d’un GPU

  • un moteur de rendu 3D, lui, a besoin d’aide
  • Vulkan se situe à un niveau inférieur au moteur de rendu
  • il existe des points de friction dans la conception de moteurs de rendu en Rust 3D

• beaucoup de mentions de Larabee, mais aucune de Xeon Phis

  • la conception des CPU se scinde entre l’optimisation des performances mono-cœur et celle de l’efficacité énergétique
  • si les cœurs E deviennent plus nombreux, les algorithmes qui exploitent le parallélisme pourraient l’emporter

• les compromis qui rendent possible le haut débit des GPU

  • il existe le système de mémoire unifiée d’Apple Silicon
  • les API de programmation GPU le traitent comme si la mémoire n’était pas unifiée