Co-Design and Evaluation of a CPU-Free MPI GPU Communication Abstraction and Implementation

Cet article présente la conception et l'évaluation d'une abstraction de communication MPI sans CPU pour les GPU, qui exploite les capacités des cartes réseau HPE Slingshot 11 pour réduire la latence et améliorer les performances sur les supercalculateurs Frontier et Tuolumne.

L'essentiel

Voici une explication simplifiée de ce papier de recherche, imagée comme si nous parlions d'une course de relais ultra-rapide.

Le Problème : Le Chef d'Orchestre trop lent

Imaginez un super-ordinateur (un "Super-Héros") qui doit résoudre des problèmes mathématiques complexes. Ce système est composé de deux équipes :

1. Les GPU (les Athlètes) : Ce sont des cerveaux ultra-rapides, spécialisés dans le calcul massif. Ils peuvent faire des millions de calculs par seconde.
2. Le CPU (le Chef d'Orchestre) : C'est le cerveau généraliste qui gère tout, y compris la communication entre les athlètes.

Le problème actuel :
Dans les systèmes traditionnels, même si les Athlètes (GPU) sont prêts à échanger des données (comme des messages), ils doivent attendre que le Chef d'Orchestre (CPU) leur donne le feu vert.

• L'analogie : Imaginez un coureur de relais qui a la baton, mais qui doit attendre que l'entraîneur (CPU) vérifie un papier, approuve le passage, et crie "Allez !" avant de pouvoir courir.
• La conséquence : Le temps perdu à attendre le chef d'orchestre (la "latence") est énorme par rapport au temps de course. Pour les petits messages, c'est comme si le coureur passait 80% de son temps à attendre le feu vert et seulement 20% à courir.

La Solution : Le "CPU-Free" (Sans Chef d'Orchestre)

Les auteurs de ce papier ont créé un nouveau système pour que les Athlètes (GPU) puissent communiquer directement entre eux, sans attendre le Chef d'Orchestre.

Comment ça marche ? (L'Analogie du Sémaphore Intelligent)
Au lieu d'attendre un ordre verbal, les athlètes utilisent un système de feux de circulation automatisé et ultra-rapide :

1. Préparation : Avant la course, on prépare tout (on fixe les règles, on s'assure que le destinataire est prêt). C'est le travail du CPU, mais il ne le fait qu'une seule fois au début.
2. L'Action : Pendant la course, quand un athlète veut envoyer un message, il ne regarde pas le chef. Il regarde un compteur spécial (un "trigger") qui lui dit : "C'est bon, tu peux lancer le message maintenant".
3. Le résultat : Le message part instantanément. Plus de temps perdu à attendre.

Les Innovations Clés du Papier

1. Le "MPI" (Le Langage de Communication) :
   Les chercheurs ont mis à jour le langage standard utilisé par les super-ordinateurs (MPI) pour qu'il accepte ce nouveau mode de communication. Ils ont ajouté une fonctionnalité appelée MPI_Match.

   • Analogie : C'est comme si, avant la course, on avait déjà apparié les coureurs (A parle à B, C parle à D) et qu'on leur avait donné des bracelets. Pendant la course, ils n'ont plus besoin de crier "Qui veut mon message ?". Ils savent déjà à qui le donner.

2. La Technologie "Slingshot" :
   Ils ont utilisé une carte réseau spéciale (HPE Slingshot 11) qui agit comme une autoroute intelligente. Cette carte sait écouter les athlètes directement et déclencher l'envoi de données sans passer par le bureau du chef.

3. L'Expérience (Le Test) :
   Ils ont testé ce système sur deux super-ordinateurs géants (Frontier et Tuolumne) en simulant un jeu célèbre : "La Vie" (Game of Life), qui nécessite beaucoup d'échanges de données entre les voisins.

   • Résultat :
     • Pour les petits messages, la latence a chuté de 50 %. C'est comme si le coureur avait doublé sa vitesse en éliminant les temps d'attente.
     • Pour les gros problèmes complexes, le système a gagné 28 % de vitesse en utilisant 8 192 GPU en même temps.

Pourquoi c'est important ?

Aujourd'hui, l'intelligence artificielle (IA) et la science des données ont besoin de faire communiquer des milliers de puces graphiques (GPU) très rapidement. Si chaque communication doit passer par un CPU, tout le système ralentit.

Ce papier montre qu'on peut supprimer le goulot d'étranglement. C'est comme passer d'une route de campagne où tout le monde s'arrête à un péage (le CPU) à une autoroute sans péage où les voitures (les données) circulent à pleine vitesse.

En résumé :
Les chercheurs ont conçu un nouveau système où les GPU parlent directement entre eux, en utilisant des signaux automatisés plutôt que des ordres manuels. Cela rend les super-ordinateurs beaucoup plus rapides, surtout pour les tâches d'intelligence artificielle et de simulation scientifique qui nécessitent des échanges de données incessants.

Résumé technique

Voici un résumé technique détaillé du papier de recherche intitulé "Co-Design and Evaluation of a CPU-Free MPI GPU Communication Abstraction and Implementation".

1. Problématique

Dans les systèmes HPC (High-Performance Computing) et d'apprentissage automatique modernes basés sur les GPU, la communication entre les nœuds est souvent un goulot d'étranglement majeur. Les approches traditionnelles de communication MPI "conscientes du GPU" (GPU-aware) nécessitent une synchronisation constante entre le CPU et le GPU. Ce processus implique :

• Le lancement de noyaux (kernels) depuis le CPU.
• Des barrières mémoire et des synchronisations de flux (stream synchronization).
• Une gestion complexe de l'appariement des messages (message matching) et de la préparation des tampons (buffer readiness).

Ces opérations introduisent des latences significatives (de l'ordre de la microseconde), ce qui peut augmenter la latence globale de 20 % à 80 % pour des messages de taille moyenne (ex: 16 Ko). De plus, les API existantes pour la communication CPU-free (sans CPU) sacrifient souvent l'expressivité (en supprimant l'appariement de messages ou la communication bidirectionnelle) ou continuent de dépendre du CPU pour la voie rapide (fast path).

L'objectif est donc de concevoir une abstraction MPI qui permette une communication bidirectionnelle (two-sided) et collective entièrement pilotée par le GPU, éliminant ainsi le CPU de la voie critique de communication tout en conservant la sémantique familière de MPI.

2. Méthodologie et Conception

Les auteurs proposent une approche de "co-conception" combinant une nouvelle API MPI et une implémentation matérielle logicielle spécifique aux cartes réseau HPE Slingshot 11.

A. L'API MPI Proposée

L'API s'appuie sur les opérations persistantes de MPI (déjà existantes) et introduit trois concepts clés :

1. MPI_Queue : Un objet qui représente un ensemble ordonné de tâches de communication à exécuter sur un flux GPU (GPU stream). Cela permet de lier la progression de la communication à l'exécution du GPU.
2. MPI_Match : Une nouvelle opération qui permet d'apparier (match) définitivement des requêtes persistantes avant leur exécution. Cela déplace la complexité de l'appariement des messages (tag matching, échange de clés RMA) hors de la voie critique de communication, permettant un déclenchement direct par le flux GPU.
3. Enfilement (Enqueueing) : Les opérations de démarrage (MPI_Enqueue_start) et d'attente (MPI_Enqueue_wait) sont ajoutées à la file d'attente. Le CPU n'intervient que pour initialiser la file et attendre la fin globale, mais ne gère pas chaque message individuellement.

B. Implémentation sur HPE Slingshot 11

L'implémentation exploite les fonctionnalités avancées de la pile logicielle libfabric (fournisseur CXI) sur les cartes Slingshot 11 :

• Compteurs de déclenchement (Triggering Counters) : Le GPU incrémente un compteur dans une zone mémoire mappée (MMIO) pour déclencher une opération.
• Files d'attente de travail différées (Deferred Work Queues - DWQ) : Les opérations de communication (comme fi_write pour les données et fi_atomic pour les notifications) sont pré-enregistrées et ne s'exécutent que lorsque le compteur de déclenchement atteint une valeur spécifique.
• Gestion de la disponibilité du récepteur (Receiver Readiness) : Pour la communication bidirectionnelle standard (qui nécessite que le récepteur soit prêt), l'implémentation utilise une séquence atomique (fi_atomic) déclenchée par la réception de données pour signaler au GPU émetteur que le tampon est prêt, évitant ainsi un aller-retour réseau supplémentaire.

3. Contributions Clés

1. Nouvelle API MPI : Conception d'une interface permettant une communication bidirectionnelle CPU-free tout en préservant la sémantique de MPI (appariement, communication collective).
2. Intégration dans Cabana/Kokkos : Démonstration de l'utilisation de cette API pour créer des objets d'échange d'halo (halo exchange) optimisés pour le framework de portabilité de performance Cabana.
3. Implémentation CPU-Free : Réalisation complète d'une communication MPI point-à-point sans CPU sur les systèmes HPE Slingshot 11, utilisant les DWQ et les compteurs de déclenchement.
4. Évaluation à grande échelle : Analyse de performance sur les supercalculateurs Frontier (ORNL) et Tuolumne (LLNL) avec jusqu'à 8 192 GPU.

4. Résultats Expérimentaux

Les évaluations ont été menées sur deux benchmarks : un micro-benchmark "Ping-Pong" et un benchmark d'échange d'halo (CabanaGhost).

• Latence et Bande Passante (Ping-Pong) :

  • Réduction de la latence jusqu'à 50 % pour les messages de taille moyenne (32 octets à 512 Ko) par rapport à Cray MPICH standard.
  • La réduction de latence est due à l'élimination des lancements de noyaux et des synchronisations CPU/GPU sur la voie critique.
  • Pour les très gros messages (> 8 Mo), Cray MPICH reste légèrement plus performant car il utilise des optimisations matérielles spécifiques (unexpected message) que l'implémentation actuelle ne gère pas encore.

• Mise à l'échelle forte (Strong Scaling) - Échange d'halo :

  • Sur le supercalculateur Frontier (jusqu'à 8 192 GPU), l'approche "Stream-Triggered Ready Send" a montré une amélioration de la vitesse de mise à l'échelle (speedup) de 28 % par rapport à Cray MPICH pour un problème de grande taille (30 Go).
  • Pour les petits problèmes, l'approche surpasse également les performances standards jusqu'à des échelles très élevées.
  • Sur Tuolumne, les tendances sont similaires, bien que la variance de performance de Cray MPICH soit plus élevée selon le nombre de GPU par nœud.

5. Signification et Impact

Ce travail démontre qu'il est possible de concevoir des abstractions de communication MPI qui éliminent complètement le CPU de la voie rapide de communication sans sacrifier la facilité d'utilisation ni la sémantique bidirectionnelle complexe (comme l'appariement de messages).

• Performance : Les gains de latence et de mise à l'échelle forte sont cruciaux pour les applications HPC intensives en communication (comme les méthodes de différences finies ou les solveurs de gradient conjugué) où la latence domine les temps d'exécution.
• Portabilité : L'approche conserve l'interface MPI standard, facilitant l'adoption par les développeurs d'applications existantes (comme Cabana) sans réécriture majeure du code.
• Futur : Bien que l'implémentation actuelle soit spécifique à Slingshot 11, les concepts (files d'attente différées, compteurs de déclenchement) ouvrent la voie à des communications CPU-free sur d'autres architectures de réseau et pourraient être étendues aux opérations collectives.

En résumé, cette recherche valide l'efficacité d'une approche de co-conception API/matériel pour repousser les limites de la communication GPU dans les systèmes exascale.