Rôles dans l'équipe¶
Six personnes, quarante-huit heures, cinq à sept charges de travail à optimiser simultanément. Sans répartition explicite, l'équipe fait six fois la même chose et personne ne couvre les entrées-sorties.
Ce chapitre propose une répartition en six rôles, avec pour chacun les compétences requises, les UE qui les donnent, et ce qu'il faut apprendre en plus.
Ces rôles sont une proposition de ce document
Les règlements de compétition n'imposent aucune spécialisation. Cette répartition est une construction, fondée sur les charges de travail réelles qu'une équipe doit couvrir. Adaptez-la à votre équipe.
Mais prenez la décision explicitement, et écrivez-la. Une équipe sans rôles définis converge spontanément vers « tout le monde regarde HPL », ce qui est le mode d'échec le plus courant.
Vue d'ensemble¶
| Rôle | Charge principale | UE déterminantes | Projet de référence |
|---|---|---|---|
| 1 · Infrastructure | Cluster, Slurm, déploiement, réseau | LOCL24, ARSE23 | P7 |
| 2 · Pile logicielle | Spack, compilateurs, MPI, bibliothèques | INPS23, ITIC23 | P11 |
| 3 · Calcul dense et HPL | HPL, HPL-MxP, GEMM, accélérateurs | PGPU35, COAV35 | P1, P9 |
| 4 · Applications scientifiques | WRF, MFC, profilage, Fortran | PRSA24, PRPA23 | P8 |
| 5 · Données et entrées-sorties | Stockage, IO500, formats, MLPerf | SYFP24, MALE24 | P13, P12 |
| 6 · Énergie et coordination | Budget électrique, planning, restitution | GIIG35, PDSP35 | P15 |
Rôle 1 · Infrastructure¶
La question dont cette personne est responsable : la machine fonctionne-t-elle, et donne-t-elle exactement les ressources demandées ?
Ce qu'elle doit savoir faire¶
- Monter et câbler le matériel, ou configurer les accès distants.
- Installer et configurer Slurm : partitions, QOS, comptabilité, et surtout les options de placement.
- Déployer des nœuds automatiquement (PXE, images, Ansible ou Puppet) et savoir reconstruire un nœud mort en moins de trente minutes.
- Diagnostiquer un réseau : vérifier que MPI utilise le réseau rapide, mesurer la latence et la bande passante, trouver pourquoi ça ne marche pas.
- Contrôler l'alimentation et les capteurs par IPMI.
- Mettre en place la surveillance (Prometheus, Grafana).
Le savoir critique¶
Le placement. C'est le geste le plus rentable et le plus souvent manqué : sans
--exclusive, --cpus-per-task, OMP_PROC_BIND et --cpu-bind cohérents, on perd
20 à 50 % sans le voir. Cette personne doit être capable d'écrire un script Slurm
correct de mémoire, et de vérifier les liaisons effectives.
Ce qu'elle doit apprendre en plus des cours¶
Tout, en réalité : aucune UE de la maquette FISA n'enseigne l'administration de cluster ni Slurm. DEVO35 donne le réflexe d'infrastructure as code (Docker, Kubernetes, GitLab CI) mais pas l'ordonnanceur. Slurm, Ansible, Spack et le diagnostic réseau InfiniBand sont donc entièrement à la charge de ce rôle. Voir Arbitrages et R3 · Cluster et Slurm, qui est exactement le programme de ce rôle.
Rôle 2 · Pile logicielle¶
La question : tout est-il construit, avec les bonnes options, et reconstructible ?
Ce qu'elle doit savoir faire¶
- Construire une pile complète avec Spack ou EasyBuild, en déclarant le MPI et les compilateurs du système en paquets externes.
- Comparer des compilateurs et des bibliothèques BLAS sur les mêmes codes.
- Gérer les conteneurs Apptainer, y compris le support MPI multi-nœuds.
- Maintenir l'intégration continue et la base de résultats.
- Diagnostiquer les erreurs de liaison, les incompatibilités d'ABI, les modules incohérents.
Le savoir critique¶
La reproductibilité. Personne dans l'équipe ne doit avoir à demander « avec quelles options as-tu compilé ça ? ». La réponse doit être dans le dépôt, et le hash Git avec les options doit figurer dans chaque résultat.
Pourquoi ce rôle est sous-estimé¶
Parce qu'il ne produit aucun chiffre de performance visible. Et parce que sans lui, l'équipe passe la première journée de la compétition à compiler. C'est le rôle qui détermine combien de temps il reste pour optimiser.
Rôle 3 · Calcul dense et HPL¶
La question : combien de FLOPS la machine délivre-t-elle, et sommes-nous au maximum ?
Ce qu'elle doit savoir faire¶
- Régler HPL : comprendre et balayer
N,NB,P,Q, choisir la bibliothèque BLAS, vérifier l'occupation mémoire. - Régler HPL-MxP et comprendre le raffinement itératif en précision mixte.
- Programmer et optimiser sur accélérateur : coalescence, mémoire partagée, recouvrement par streams, multi-accélérateur, GPU-aware MPI.
- Mesurer le pic réel de la machine et savoir quel pourcentage HPL en atteint.
- Utiliser les unités matricielles et comprendre les compromis de précision.
Le savoir critique¶
Le pourcentage du pic. Cette personne doit pouvoir dire, à tout moment : « nous sommes à 78 % du pic théorique, et les 22 % restants sont dus à tel mécanisme ». Sans cela, on ne sait pas s'il faut continuer à régler ou passer à autre chose.
Les chiffres de référence à connaître¶
| Situation | Pourcentage du pic attendu sur HPL |
|---|---|
| Cluster mal réglé | 50 à 65 % |
| Cluster correctement réglé | 80 à 90 % |
| Machine du Top500 optimisée | 70 à 90 % selon l'architecture |
Rôle 4 · Applications scientifiques¶
La question : ce code que nous ne connaissons pas, où passe-t-il son temps, et comment l'accélérer sans le casser ?
Ce qu'elle doit savoir faire¶
- Compiler une application inconnue, y compris en Fortran, avec ses dépendances.
- La profiler :
perf, mpiP, LIKWID, et savoir lire le résultat. - Identifier le régime (compute ou memory bound) et positionner sur le roofline.
- Trouver les paramètres d'exécution optimaux : décomposition de domaine, nombre de rangs et de threads, placement.
- Valider numériquement après chaque modification.
- Lire la documentation d'une application en une heure et en extraire les paramètres qui comptent.
Le savoir critique¶
La vitesse de diagnostic. En compétition, on reçoit une application inconnue et on a quelques heures. Il faut avoir une procédure : compiler, faire tourner un petit cas, profiler, identifier le point chaud, chercher les paramètres. Cette procédure s'entraîne, et c'est l'objet de l'exercice de « chasse à l'aveugle » du chapitre Outils de mesure.
Le manque à combler¶
Le Fortran. WRF et MFC, les deux applications annoncées pour SC26, sont en Fortran. Dix heures de préparation, décrites dans Build et environnement.
Rôle 5 · Données et entrées-sorties¶
La question : combien de temps perdons-nous à lire et à écrire, et combien pouvons-nous en récupérer ?
Ce qu'elle doit savoir faire¶
- Profiler les E-S avec Darshan et interpréter le rapport.
- Identifier le régime (bande passante ou métadonnées).
- Régler un système de fichiers parallèle : striping, taille de requête, alignement.
- Utiliser IOR et mdtest, et exécuter IO500 si le règlement l'inclut.
- Optimiser le chargement de données d'un entraînement de réseau de neurones — qui est un problème d'E-S déguisé, et le goulot le plus fréquent de MLPerf.
Le savoir critique¶
Le fait que les E-S sont souvent le premier gain disponible, précisément parce que personne ne les regarde. Sur une application scientifique réelle mal configurée, un facteur deux sur le temps total par une refonte des E-S est courant.
Pourquoi ce rôle est le plus négligé¶
Parce qu'il n'est pas glorieux et qu'il ne figure pas dans les récits de compétition. C'est précisément pour cela qu'il est un avantage compétitif : les équipes concurrentes ne l'ont probablement pas couvert.
Rôle 6 · Énergie et coordination¶
La question : restons-nous sous le budget électrique, et travaillons-nous sur la bonne chose maintenant ?
Ce qu'elle doit savoir faire¶
- Mesurer la puissance en temps réel (RAPL,
nvidia-smi, IPMI) et la journaliser. - Appliquer des plafonds de puissance et connaître la courbe performance-puissance du matériel.
- Décider, sous contrainte, quel composant bride et lequel on laisse à fond.
- Tenir le planning des quarante-huit heures, arbitrer les priorités, décider quand abandonner une piste.
- Préparer et conduire la restitution : les entretiens avec le jury, l'explication des choix.
Le savoir critique¶
Que le pic déclenche la pénalité, pas la moyenne. Un HPL a un profil de puissance non uniforme, et le pic peut dépasser le seuil pendant quelques secondes. La surveillance doit donc être continue, avec une alerte, et une marge de sécurité.
Pourquoi la coordination est un rôle à part entière¶
Parce qu'en quarante-huit heures, la principale ressource gaspillée est l'attention. Sans quelqu'un qui tient le planning et arbitre, l'équipe entière converge vers le problème le plus intéressant plutôt que vers le plus rentable. Ce rôle n'est pas « celui qui ne fait rien de technique » : c'est celui qui décide où va le temps des cinq autres.
Les recouvrements nécessaires¶
Six rôles ne signifient pas six silos. Trois compétences doivent être partagées par au moins deux personnes, pour que l'absence ou la fatigue de l'une ne bloque pas l'équipe.
Les trois points de défaillance unique à éliminer
- Slurm et le placement. Si une seule personne sait écrire un script de soumission correct, l'équipe s'arrête quand elle dort. Au moins trois personnes doivent savoir le faire.
- La construction de la pile. Si une seule personne sait reconstruire l'environnement, une erreur de sa part immobilise tout le monde. Documentez, et faites répéter par quelqu'un d'autre.
- La validation numérique. Chacun doit savoir vérifier que le résultat de son application est correct. Un code rapide et faux ne rapporte rien, et pire, il fait perdre du temps à en chercher la cause au mauvais endroit.
La règle des trois quarts¶
Un point de méthode sur le sommeil
Quarante-huit heures de compétition, six personnes. La tentation est que tout le monde reste éveillé. C'est le plus sûr moyen de prendre de mauvaises décisions dans les douze dernières heures, qui sont les plus importantes.
Organisez des rotations dès la première heure, avec un tableau écrit. Au moins quatre personnes éveillées en permanence, chacune dormant quatre à six heures par période de vingt-quatre. Et un principe : celui qui vient de dormir relit les décisions prises pendant son absence.
Ce n'est pas un détail de confort : c'est une décision de performance.
La grille d'auto-évaluation de l'équipe¶
Avant de candidater, remplissez ce tableau. Chaque ligne doit avoir au moins un nom, et idéalement deux.
| Compétence | Qui ? | Qui en second ? |
|---|---|---|
| Écrire un script Slurm correct avec placement | ||
| Reconstruire la pile logicielle de zéro | ||
| Régler HPL et expliquer le pourcentage du pic | ||
| Profiler une application inconnue en Fortran | ||
| Diagnostiquer et corriger un problème d'E-S | ||
| Mesurer et limiter la puissance | ||
| Programmer et optimiser sur accélérateur | ||
| Valider numériquement un résultat | ||
| Lire un rapport de vectorisation du compilateur | ||
| Présenter un résultat à un jury en dix minutes |
Une ligne vide est une candidature affaiblie. Le chapitre Plan d'entraînement donne l'ordre dans lequel les combler.
À retenir¶
Les quatre règles d'organisation
- Six rôles explicites, écrits, décidés à l'avance. Une équipe sans rôles regarde tous HPL et néglige les E-S.
- Le rôle le plus sous-estimé est la pile logicielle : il ne produit aucun chiffre, et il détermine combien de temps il reste pour optimiser.
- Le rôle le plus négligé par les concurrents est les entrées-sorties. C'est donc un avantage compétitif.
- Trois compétences doivent être partagées : Slurm et le placement, la construction de la pile, et la validation numérique. Sinon vous avez trois points de défaillance unique qui dorment.
Chapitre suivant : Anatomie d'une compétition.