Anatomie d'une compétition¶

Ce chapitre décrit les épreuves : ce que mesurent les benchmarks, comment on les règle, et à quoi ressemblent quarante-huit heures de compétition.

Les règles citées sont celles de la SCC de SC26, relevées le 17 septembre 2026. Les mécanismes techniques décrits sont généraux.

Les benchmarks de SC26¶

Fait. Trois benchmarks annoncés : HPL, HPL-MxP et MLPerf Training. Plus deux applications scientifiques : WRF et MFC.

HPL, ou le Top500 en miniature¶

Ce qu'il calcule¶

HPL résout un système linéaire dense \(Ax = b\) d'ordre \(N\) par factorisation LU avec pivotage partiel, puis substitutions. Le nombre d'opérations flottantes est connu exactement :

\[ F = \frac{2}{3}N^3 + 2N^2 \]

La performance rapportée est \(F/t\) où \(t\) est le temps mesuré.

Pourquoi il atteint un fort pourcentage du pic¶

Parce que le travail dominant est du GEMM, donc du BLAS niveau 3, dont l'intensité arithmétique croît avec la taille des blocs. C'est le benchmark le plus favorable possible à une machine. Voir Solveurs.

Les quatre paramètres à régler¶

Dans le fichier HPL.dat :

Paramètre	Signification	Comment le choisir
N	Ordre de la matrice	Le plus grand possible, occupant 80 à 90 % de la mémoire totale disponible. La matrice fait \(8N^2\) octets en double précision
NB	Taille de bloc	Typiquement entre 100 et 400, à balayer. Dépend de la bibliothèque BLAS et de la taille des caches
P, Q	Grille de processus	\(P \times Q\) = nombre de rangs. Choisir \(P \le Q\), et \(P\), \(Q\) aussi proches que possible d'un carré

Le calcul de N. Avec \(M\) octets de mémoire totale utilisable et un taux d'occupation \(\alpha\) :

\[ N \approx \sqrt{\frac{\alpha M}{8}} \]

Exemple numérique. Pour un cluster de 4 nœuds à 256 Go chacun, soit \(M = 1{,}024 \times 10^{12}\) octets, avec \(\alpha = 0{,}85\) :

\[ N \approx \sqrt{\frac{0{,}85 \times 1{,}024 \times 10^{12}}{8}} \approx 330\,000 \]

Et le nombre d'opérations serait alors \(\frac{2}{3} \times (3{,}3\times10^5)^3 \approx 2{,}4 \times 10^{16}\) opérations flottantes. À 100 TFLOP/s, cela prend environ quatre minutes. Ces ordres de grandeur permettent de planifier : un HPL de production dure de quelques minutes à quelques heures, et on ne peut pas en lancer cinquante dans une journée. D'où l'importance de balayer les paramètres sur des tailles réduites avant.

La méthode de réglage de HPL, en quatre étapes

1. Balayer NB à petit N. Prendre un N qui donne une exécution de trente secondes, et tester une dizaine de valeurs de NB. L'optimum trouvé reste généralement valable à grand N.

2. Balayer la grille P × Q à petit N également, pour un nombre de rangs donné.

3. Décider du nombre de rangs et de threads par rang. Sur un nœud à accélérateurs, en général un rang par accélérateur. Sur un nœud sans accélérateur, un rang par domaine NUMA avec les threads BLAS dedans.

4. Puis, et seulement alors, lancer le grand N. En surveillant la mémoire (un dépassement provoque un échec après plusieurs minutes de calcul) et la puissance.

Le piège : N trop grand provoque du swap ou un échec d'allocation, et on perd l'exécution entière. Prévoyez une marge : commencez à 80 % et montez.

Le rapport à la puissance¶

HPL est le benchmark qui consomme le plus, parce qu'il sature les unités de calcul. C'est donc sur HPL que le risque de dépassement du budget électrique est le plus élevé, et que le plafonnement de puissance est le plus utile. Voir Énergie.

HPL-MxP, la précision mixte¶

Ce qu'il change¶

Même problème, mais résolu en précision réduite puis raffiné itérativement pour retrouver la précision de la double précision.

Le principe du raffinement itératif : on factorise \(A\) en précision réduite, on résout, puis on calcule le résidu \(r = b - Ax\) en précision élevée, on résout \(A\,\delta = r\) avec la factorisation en précision réduite, et on corrige \(x \leftarrow x + \delta\). Quelques itérations suffisent à récupérer la précision.

Le gain vient du fait que la factorisation, qui coûte \(O(N^3)\), se fait en précision réduite avec les unités matricielles des accélérateurs, tandis que les corrections, qui coûtent \(O(N^2)\), se font en précision élevée.

Pourquoi c'est un bon benchmark¶

Parce qu'il récompense l'exploitation des unités matricielles, qui sont la caractéristique dominante des accélérateurs modernes, et parce que la technique est réellement utile : de nombreux solveurs de production l'emploient.

Ce qu'il faut savoir en plus¶

Les formats de précision réduite ne sont pas équivalents. Voir GPU et hétérogène. Et la convergence du raffinement dépend du conditionnement de la matrice : sur un problème mal conditionné, la technique échoue.

MLPerf Training¶

Ce qu'il mesure¶

Le temps pour atteindre une précision cible sur un modèle et un jeu de données imposés. Ce n'est pas un débit brut, et c'est un choix méthodologique important : doubler la taille du lot double souvent le débit en échantillons par seconde tout en dégradant la convergence, donc sans améliorer la métrique.

Où se joue la performance¶

Par ordre de fréquence des goulots observés :

Le chargement des données. C'est le goulot numéro un, et il est ignoré par la plupart des gens. Nombre de travailleurs, mémoire épinglée, pré-chargement, format des données sur disque. C'est un problème d'entrées-sorties, donc le rôle 5 de l'équipe.
La précision mixte. BF16 ou FP16 avec les unités matricielles : facteur deux à plusieurs, et il faut vérifier la convergence.
La synchronisation des gradients en multi-accélérateur : un Allreduce par pas, recouvrable avec la passe arrière.
Le réglage des hyperparamètres dans les limites autorisées par le règlement, qui définit ce qui est modifiable.

Le préalable¶

Lire le règlement de MLPerf. Il définit précisément ce qui est autorisé — quels hyperparamètres peuvent être ajustés, quelles optimisations sont considérées comme des modifications du modèle. Les soumissions publiques contiennent les configurations complètes, ce qui en fait un manuel d'optimisation implicite.

Les applications scientifiques¶

WRF¶

Le Weather Research & Forecasting Model, un modèle de prévision météorologique, écrit en Fortran, largement utilisé en opérationnel et en recherche.

Ce qui compte pour la performance :

la décomposition de domaine : WRF découpe la grille en tuiles, et le rapport entre le nombre de rangs MPI et le nombre de threads OpenMP par rang est un paramètre majeur ;
les entrées-sorties, qui sont volumineuses (le modèle écrit des champs 3D à chaque pas de sortie) et pour lesquelles WRF propose plusieurs stratégies configurables, dont des serveurs d'E-S dédiés ;
le choix du compilateur et des options : sur un code Fortran de cette taille, l'écart entre compilateurs est significatif ;
la physique activée : le cas test impose les paramétrisations, mais leur coût relatif détermine où optimiser.

MFC¶

Le Multicomponent Flow Code, un code d'écoulements multiphasiques compressibles, également en Fortran, avec un support d'accélérateurs.

Ce qui compte : la même liste, plus la question du portage sur accélérateur et du rapport calcul/communication selon la taille des sous-domaines.

La procédure de prise en main d'une application inconnue

À répéter jusqu'à ce qu'elle devienne un réflexe. Chronométrez-vous : l'objectif est moins de trois heures pour les six étapes.

Lire le guide d'installation et compiler, avec les dépendances minimales. Noter toutes les options utilisées.
Faire tourner le plus petit cas test fourni et vérifier qu'il produit la sortie de référence.
Chronométrer les phases : initialisation, calcul, E-S. Instrumenter si le code ne le fait pas.
Profiler avec perf et mpiP sur un cas moyen. Identifier les trois fonctions dominantes et la fonction MPI dominante.
Balayer les paramètres d'exécution : nombre de rangs, threads par rang, décomposition, placement. C'est souvent ici que se trouve le premier facteur deux, sans toucher une ligne de code.
Lire la documentation sur les options de performance. Les codes matures en ont une, et elle contient des réglages que personne ne lit.

Les étapes 5 et 6 rapportent généralement plus que toute modification du code, et coûtent beaucoup moins de temps. Faites-les d'abord.

Les autres benchmarks à connaître¶

Ils ne figurent pas dans le règlement de SC26 mais apparaissent dans d'autres éditions et compétitions, et ils servent à caractériser la machine.

Benchmark	Ce qu'il mesure	Usage
HPCG	Gradient conjugué creux préconditionné	Second classement officiel du Top500. 1 à 5 % du pic, donc représentatif des codes réels
STREAM	Bande passante mémoire	Indispensable pour établir la borne du roofline
OSU Micro-Benchmarks	Latence et bande passante MPI	Vérifier que le réseau rapide fonctionne
BabelStream	Bande passante, portable CPU et accélérateurs	Caractériser un accélérateur
IO500	Stockage, bande passante et métadonnées	Si le stockage est évalué
Graph500	Parcours de graphe (BFS)	Un régime très différent : accès aléatoires, latence
HPCC	Suite de sept benchmarks	Vue d'ensemble d'une machine

Pourquoi HPCG mérite d'être compris même s'il n'est pas au programme

Parce que l'écart entre HPL et HPCG sur la même machine, qui atteint un facteur vingt à cinquante, est la meilleure question d'entretien du domaine. Savoir y répondre — intensité arithmétique, régime memory bound, coût synchronisant de l'Allreduce par itération — démontre la compréhension de l'ensemble.

Voir Solveurs.

Les quarante-huit heures, heure par heure¶

Un découpage indicatif, fondé sur la logique des charges de travail. À adapter au règlement réel de l'édition.

Avant : les jours de montage¶

Sur la SCC de SC, l'équipe monte son cluster sur le salon avant le début officiel. C'est là que se règlent les problèmes matériels, et c'est le moment le plus stressant de la compétition.

Ce qui doit être prêt avant d'arriver :

la pile logicielle complète, testée sur une machine identique ou proche ;
tous les scripts de lancement, testés ;
le carnet de réglages, avec les paramètres optimaux par benchmark ;
la surveillance de puissance, opérationnelle ;
la procédure de reconstruction d'un nœud.

H+0 à H+4 · Validation et caractérisation¶

Vérifier que tous les nœuds répondent, que le réseau est au bon débit (OSU), que la mémoire est à la bonne bande passante (STREAM).
Établir la puissance au repos et la puissance sous charge maximale.
Lancer un HPL court pour valider la chaîne complète.

Ne commencez pas à optimiser avant d'avoir validé. Une équipe qui optimise sur un nœud dont le réseau est mal configuré perd des heures.

H+4 à H+16 · Le premier tour sur tout¶

Faire tourner chaque épreuve une fois, avec une configuration raisonnable, et enregistrer le résultat. Objectif : avoir un chiffre pour tout, même mauvais.

Pourquoi c'est la bonne stratégie : un chiffre médiocre partout vaut mieux qu'un excellent chiffre sur HPL et rien ailleurs. Et cela révèle immédiatement où sont les marges.

H+16 à H+36 · L'optimisation, par priorité¶

Classer les épreuves par marge estimée : où sommes-nous le plus loin de la borne ? Et travailler dans cet ordre, par blocs de deux à trois heures, avec un point d'équipe entre chaque bloc.

Le rôle 6 arbitre. La question à chaque point : « cette piste a-t-elle encore une marge, ou faut-il passer à autre chose ? »

H+36 à H+44 · Les exécutions finales¶

Relancer chaque épreuve dans sa meilleure configuration, et enregistrer proprement. C'est le moment où l'on ne prend plus de risque : pas de nouvelle optimisation, pas de recompilation.

La règle : toute exécution finale doit avoir été validée au moins une fois dans la même configuration. On ne découvre pas un paramètre à H+40.

H+44 à H+48 · La restitution¶

Préparer les résultats, les figures, et l'explication des choix. Les entretiens avec le jury pèsent, et une équipe qui ne sait pas expliquer ses chiffres perd des points.

Les cinq erreurs classiques des quarante-huit heures

Optimiser avant d'avoir validé la machine. Des heures perdues sur un symptôme causé par une mauvaise configuration réseau.
Passer les trois quarts du temps sur HPL parce que c'est le plus satisfaisant à régler. Les points sont ailleurs aussi.
Recompiler à H+40. Toute modification tardive doit être proscrite par règle interne.
Ne pas enregistrer les configurations des bonnes exécutions. On obtient un excellent chiffre et on ne sait plus le reproduire.
Ne pas dormir. Les douze dernières heures sont les plus importantes, et elles se jouent sur la qualité des décisions.

À retenir¶

Les six points de l'anatomie

HPL : factorisation LU dense, \(\frac{2}{3}N^3\) opérations, 80 à 90 % du pic quand c'est bien réglé. Balayer NB et P × Q à petit N avant de lancer le grand.
HPL-MxP : raffinement itératif en précision mixte, pour exploiter les unités matricielles.
MLPerf : la métrique est le temps pour atteindre une précision cible, et le goulot est presque toujours le chargement des données.
Les applications sont en Fortran. La procédure de prise en main, en six étapes et moins de trois heures, s'entraîne.
Les étapes 5 et 6 de cette procédure — balayer les paramètres d'exécution et lire la documentation de performance — rapportent plus que toute modification du code.
Le premier tour sur tout avant d'optimiser quoi que ce soit. Un chiffre médiocre partout vaut mieux qu'un excellent chiffre et quatre absences.

Sources¶

Student Cluster Competition – SC26 — règles, puissance, benchmarks et applications
HPL – Netlib — la spécification et le fichier HPL.dat
HPCG Benchmark
STREAM
IO500
MLCommons – MLPerf

Chapitre suivant : Éligibilité et candidature.