Projets avancés¶

Cinq projets de niveau fin de cursus, à faire pendant les semestres 4 et 5, en RDEV36, ou dans le cadre d'une préparation de compétition. Chacun est un travail de plusieurs semaines et peut constituer un livrable noté.

Charge totale : environ 220 heures. N'en faites qu'un ou deux.

P11 · Le banc d'essai complet de compétition¶

⏱ 50 h · ★★★★ · Le projet le plus utile si vous visez une compétition

Pourquoi celui-là¶

Parce que les équipes perdent la moitié de leur temps de compétition sur des problèmes de construction, de lancement et de collecte de résultats — du travail qu'on peut faire entièrement à l'avance.

Le sujet¶

Construire l'infrastructure logicielle complète d'une équipe, et la valider sur les benchmarks réels d'une compétition.

Les sept composants :

Un dépôt structuré : un répertoire par application, un par famille de scripts, un pour les configurations machine, un pour les résultats. Documenté pour un nouvel arrivant.
Des recettes de construction reproductibles : un environnement Spack ou EasyBuild qui installe une pile complète (compilateurs, MPI, BLAS, FFTW, HDF5, NetCDF) sur une machine vierge. Testé sur deux machines différentes.
Les benchmarks installés et réglés :
HPL : construit contre une BLAS optimisée, avec un balayage des paramètres N, NB, P, Q documenté et un optimum trouvé ;
HPL-MxP : la variante en précision mixte ;
HPCG ;
STREAM et OSU Micro-Benchmarks pour caractériser la machine ;
IO500 si le stockage compte ;
MLPerf, au moins un banc d'entraînement.
Les applications scientifiques : au moins deux applications réelles compilées, validées, et pour lesquelles un cas test représentatif tourne. WRF et MFC sont les deux annoncées pour la SCC de SC26.
Un lanceur unifié : un script qui prend un nom d'application, une taille de problème et un nombre de nœuds, génère le script Slurm adéquat avec le bon placement, le soumet, et enregistre le résultat avec ses métadonnées.
Une base de résultats : une ligne par exécution, avec application, paramètres, machine, compilateur, options, nœuds, rangs, threads, temps, métrique, puissance, hash du code, date, auteur.
Un tableau de bord : la meilleure performance par application, l'historique, la configuration correspondante, et le suivi de puissance en temps réel.

Le critère de réussite¶

Donner le dépôt à quelqu'un qui n'a pas participé, et qu'il puisse en moins d'une heure, sans poser de question, construire une application et reproduire une mesure.

Le livrable annexe¶

Un carnet de réglages : pour chaque benchmark et chaque machine, les paramètres optimaux trouvés et l'explication. C'est le document que l'équipe consultera pendant les quarante-huit heures, et il doit tenir sur deux pages par benchmark.

Liens : Anatomie d'une compétition, Build et environnement, Monter une équipe.

P12 · L'optimisation d'un entraînement distribué¶

⏱ 40 h · ★★★★ · Recoupe MALE24

Pourquoi celui-là¶

Parce que MLPerf Training figure au programme de la compétition SC26, parce que l'entraînement est la charge dominante des grands centres, et parce que traiter l'apprentissage avec la rigueur du HPC — modèle, borne, mesure — est encore rare.

Le sujet¶

Traiter un entraînement de réseau de neurones comme un problème de calcul parallèle.

Le modèle : un ResNet sur CIFAR-10 ou un sous-ensemble d'ImageNet, un petit transformeur sur un corpus de texte, ou un auto-encodeur sur des données de simulation que vous avez produites vous-même en P5.

Les sept parties :

Comptage analytique. Nombre d'opérations flottantes par pas d'entraînement (passe avant, passe arrière : environ deux fois la passe avant, mise à jour). Volume en octets des paramètres, activations, gradients et états de l'optimiseur. Établir la borne avant toute mesure.
Mesure de référence sur un accélérateur : temps par pas, GFLOPS effectifs, pourcentage du pic — en tenant compte du format de calcul utilisé.
Profilage avec Nsight Systems pour la chronologie et Nsight Compute pour les noyaux, ou le profileur intégré du framework. La question centrale : quelle fraction du temps l'accélérateur passe-t-il inactif, et pourquoi ?
Optimisation du chargement de données. C'est le goulot le plus fréquent et le plus ignoré : nombre de travailleurs, mémoire épinglée, pré-chargement, format des données sur disque. C'est souvent le premier facteur deux, et il ne coûte aucune modification du modèle.
Précision mixte : passer en BF16 ou FP16 avec les unités matricielles. Mesurer le gain et vérifier que la convergence n'est pas dégradée — c'est la partie que les gens oublient.
Passage à plusieurs accélérateurs avec le parallélisme de données. Courbe d'accélération, et décomposition du temps en calcul, synchronisation des gradients, et chargement.
Synthèse : un tableau de toutes les optimisations avec leur gain mesuré, et le positionnement du résultat final par rapport à la borne de la partie 1.

La métrique correcte¶

Attention : le débit brut en échantillons par seconde n'est pas la bonne métrique. Doubler la taille du lot double souvent le débit mais dégrade la convergence, donc allonge le temps pour atteindre une précision cible. La métrique de MLPerf est le temps pour atteindre une précision cible, et c'est la seule honnête. Rapportez les deux.

Liens : GPU et hétérogène, MALE24.

P13 · La refonte des entrées-sorties d'un code de production¶

⏱ 35 h · ★★★★ · Recoupe SYFP24

Pourquoi celui-là¶

Parce que c'est le poste d'optimisation le plus négligé et souvent le plus rentable, et parce que peu de gens savent le faire.

Le sujet¶

Diagnostiquer et améliorer le comportement d'entrées-sorties d'un code de simulation réel.

Candidats : OpenFOAM (notoirement mauvais : il écrit un répertoire par pas de temps et par processus, ce qui est l'antipatron absolu), LAMMPS, GROMACS, Code_Saturne, ou un code de votre entreprise.

Les six étapes :

Faire tourner le code à une échelle modeste et mesurer la répartition du temps entre calcul, communication et entrées-sorties.
Profiler avec Darshan : nombre de fichiers ouverts, distribution des tailles de requête, proportion d'accès séquentiels, déséquilibre entre rangs, temps d'E-S par rang.
Identifier le régime : bande passante ou métadonnées ? La réponse détermine tout le reste.
Formuler une hypothèse chiffrée : « en passant de \(N\) fichiers à un fichier partagé avec un striping de 16 et des requêtes de 4 Mo, je devrais passer de \(x\) Mo/s à environ \(y\) Mo/s, parce que… »
Implémenter et mesurer. L'écart entre la prédiction et la mesure est la partie la plus instructive.
Rédiger un rapport d'expertise de huit pages : contexte, mesures, diagnostic, action, résultat, limites.

Le résultat réaliste¶

Sur un code qui fait un fichier par processus, le passage à des E-S collectives en Parallel HDF5 donne couramment un facteur cinq à cinquante à grande échelle, et réduit de plusieurs ordres de grandeur la charge sur le serveur de métadonnées — ce qui rend service à tous les autres utilisateurs de la machine.

Le bonus¶

Si le code est libre, proposez le correctif en amont. Une contribution acceptée sur les E-S d'un code largement utilisé est un travail visible et utile.

Liens : SYFP24, Entrées-sorties et stockage.

P14 · Le simulateur de circuits quantiques haute performance¶

⏱ 40 h · ★★★★ · Recoupe IQRO35 et IQRO35

Pourquoi celui-là¶

Parce qu'il transforme deux UE sans rapport avec la performance en un exercice de calcul intensif de premier ordre, et parce que c'est un vrai problème : les grands simulateurs quantiques sont des codes HPC hautement optimisés qui tournent sur les plus grosses machines du monde.

Le sujet¶

Écrire un simulateur de circuits quantiques par vecteur d'état et l'optimiser comme un code HPC.

Les six étapes :

Version de référence : un vecteur de \(2^n\) amplitudes complexes, application d'une porte à un qubit par parcours du vecteur, portes à deux qubits, mesure. Validation contre Qiskit sur des circuits de test.
Analyse : quelle est l'intensité arithmétique de l'application d'une porte à un qubit ? Quelques opérations complexes pour deux lectures et deux écritures de nombres complexes — donc une intensité très faible. Le problème est limité par la bande passante mémoire, ce qui détermine toute la suite. Position sur le roofline.
Optimisation mémoire : disposition des amplitudes (parties réelle et imaginaire entrelacées ou séparées ?), et surtout la fusion de portes — appliquer plusieurs portes successives sur un bloc d'amplitudes tant qu'il est en cache, plutôt que de balayer tout le vecteur pour chaque porte. C'est l'optimisation centrale du domaine, et elle peut donner un facteur important.
Le problème du motif d'accès : appliquer une porte au qubit \(k\) accède des amplitudes séparées par \(2^k\). Pour \(k\) petit, les accès sont locaux ; pour \(k\) grand, chaque accès est sur une page différente et le cache est inutile. Trouver comment y remédier — par réordonnancement, par traitement de plusieurs qubits à la fois, ou par transposition — est le cœur technique du projet.
Vectorisation et parallélisation OpenMP, avec attention à la première touche sur un vecteur qui peut faire des dizaines de gigaoctets.
Extension MPI : au-delà d'environ 30 qubits, le vecteur d'état ne tient plus dans la mémoire d'un nœud. Il faut le distribuer, et les portes sur les qubits de poids fort deviennent alors des communications globales — typiquement un MPI_Alltoall ou un échange par paires. C'est exactement le problème que résolvent les simulateurs de production.

Livrables¶

Le code, le tableau des optimisations avec leurs gains, le nombre maximal de qubits atteint sur votre matériel, un graphique du nombre de qubits simulables en fonction de la mémoire disponible avec la loi en \(2^n\) tracée, et une comparaison à Qiskit Aer.

Le chiffre à obtenir¶

Sur une machine ordinaire, la limite est vers 30 à 33 qubits (un vecteur de \(2^{33}\) nombres complexes en double précision représente 128 Go). Sur un cluster, on peut aller plus loin, et le record mondial en simulation exacte est de l'ordre de 45 à 50 qubits sur les plus grandes machines. Situer votre résultat dans cette échelle donne la mesure de ce que représente un supercalculateur.

P15 · L'étude de performance publiable¶

⏱ 40 h · ★★★★ · Recoupe PDSP35 et RDEV36

Pourquoi celui-là¶

Parce que produire une étude de performance défendable est la compétence la plus transférable de tout le parcours, et parce que c'est le format attendu de l'évaluation de PDSP35.

Le sujet¶

Choisir une question de recherche et y répondre selon les standards d'un article de conférence.

Exemples de questions bien formées :

« Jusqu'à quelle échelle le solveur X passe-t-il à l'échelle sur la machine Y, et quel mécanisme précis limite son efficacité au-delà ? »
« Le modèle roofline prédit-il correctement la performance de N noyaux sur trois machines différentes ? Où échoue-t-il, et pourquoi ? »
« Quel est le compromis performance-énergie de l'application A en fonction du nombre de cœurs actifs et du plafond de puissance, et existe-t-il un point de fonctionnement meilleur que le défaut ? »
« Quelle est la sensibilité du temps d'exécution de B au placement des processus sur la topologie réseau, et quel gain un placement optimisé apporte-t-il ? »
« Quel écart de performance et d'effort de développement existe-t-il entre CUDA, SYCL, Kokkos et OpenMP target sur un noyau représentatif, et sur deux architectures ? »

Les sept sections, dans le format d'un article :

Introduction et question, une page, avec la contribution annoncée.
Contexte et travaux antérieurs : au moins cinq articles réellement lus, avec ce que chacun apporte et ce qui manque.
Méthodologie : machine, compilateur et version, options, jeux de données, répétitions, statistique, procédure exacte. Quelqu'un doit pouvoir refaire l'expérience.
Modèle : la prédiction analytique, posée avant les mesures.
Résultats : figures propres, barres d'erreur, confrontation au modèle.
Discussion : l'explication des écarts. C'est la partie scientifique.
Limites et menaces à la validité, honnêtement. Une seule machine ? Un seul compilateur ? Un jeu de données non représentatif ? C'est la section qui distingue un travail sérieux.

Le livrable annexe¶

Un dépôt contenant les scripts, les données brutes et les notebooks de figures, permettant de tout régénérer. C'est la définition opérationnelle de la reproductibilité.

La lecture obligatoire avant de commencer¶

Hoefler & Belli, « Scientific Benchmarking of Parallel Computing Systems », SC 2015. Douze règles de mesure. Appliquez-les toutes, explicitement, et dites-le dans la section méthodologie. Cela met immédiatement votre travail au-dessus de la moyenne de la littérature.

Liens : PDSP35, Modèles de performance, Outils de mesure.

Le bilan des avancés¶

Ce que ces projets démontrent

Un seul de ces cinq projets, mené jusqu'au bout et correctement documenté, démontre :

que vous savez poser une question mesurable et y répondre ;
que vous savez modéliser avant de mesurer ;
que vous savez construire un environnement reproductible ;
que vous savez écrire un rapport technique qu'un professionnel peut lire ;
et que vous êtes honnête sur les limites de votre travail.

C'est exactement ce que cherche un encadrant de thèse, un recruteur en centre de calcul, et un jury de compétition. Un projet fini vaut mieux que cinq projets commencés : c'est le sujet du chapitre suivant.

Chapitre suivant : Comment choisir.