R2 · Programmation scientifique, de la chaîne à la performance¶

Le module le plus lourd de la reconstitution, et celui qui rapporte le plus.


Volume	⏱ 80 h, en deux volets
Quand	Volet A pendant le S3, volet B pendant le S4 — ou en continu sur l'année
Prérequis	R1 · C++ pour le calcul, Linux en ligne de commande, algèbre linéaire
Ce que la maquette FISA donne déjà	Rien. ITIC23 donne les tests et l'intégration continue, DEVO35 le déploiement ; le calcul scientifique lui-même n'a aucune UE
Livrable	Une chaîne de calcul complète, mesurée et reproductible, dans votre dépôt

D'où vient ce module

Il fusionne deux UE de la formation sous statut étudiant, qui se suivaient et se citaient en prérequis :

INPS23 · Introduction à la programmation scientifique (S3) → volet A ;
PRSA24 · Programmation scientifique avancée (S4) → volet B.

Leurs deux syllabus laissaient le contenu des modules non détaillé. Ce qui suit est donc une reconstitution à partir de leurs objectifs cités, de leurs prérequis et de leurs grilles de compétences — et non la copie d'un programme publié.

Pourquoi ce module est le premier de la liste¶

La « chaîne » est la compétence sous-estimée du HPC. Le grand public du domaine imagine que le travail consiste à optimiser des boucles. En réalité, un ingénieur en calcul intensif passe la majorité de son temps sur :

la construction de l'environnement (compilateurs, bibliothèques, modules) ;
le lancement et le suivi de campagnes de calcul (scripts, ordonnanceur, reprise sur erreur) ;
la gestion des données produites (formats, volumes, métadonnées) ;
le post-traitement et la visualisation ;
la reproductibilité de tout cela.

Et c'est exactement ce que fait une équipe de Student Cluster Competition pendant les trois quarts des quarante-huit heures : construire, lancer, surveiller, relancer, extraire, présenter.

Le volet B, lui, se superpose terme à terme avec l'épreuve elle-même :

Objectif cité de PRSA24	Student Cluster Competition
« codes réalistes »	Applications scientifiques réelles imposées par le jury
« architectures massivement parallèles »	Un cluster de plusieurs nœuds, souvent avec GPU
« mise en production »	Construire, lancer, faire tourner en 48 h
« monitoring »	Surveiller la consommation électrique et la progression
« profiling »	Trouver le point chaud d'un code qu'on ne connaît pas
« re-factoring »	Le modifier sans le casser
« visualisation de données »	Présenter les résultats au jury

Le raccourci qu'un apprenti a et qu'un étudiant n'a pas

Ce module demande un code réel, non trivial, que quelqu'un utilise. Un étudiant doit s'en inventer un. Vous en avez un sous la main : celui de votre entreprise. Faites porter les deux volets sur le même code, et ce module devient un livrable professionnel au lieu d'un exercice.

C'est aussi le meilleur germe de sujet de PFE.

Volet A · La chaîne de calcul · ⏱ 45 h¶

L'objectif cité d'INPS23 :

« Cette UE consiste en la présentation des différentes briques fonctionnelles intervenant lors du développement d'un code de calcul scientifique, de son exploitation en phase de production, et enfin lors de la phase d'extraction et de présentation des résultats. »

Arriver prêt¶

⏱ 15 h. C'est le volet dont la mise en route rapporte le plus, parce que les prérequis sont nombreux et qu'aucun n'est enseigné.

C++ — condition d'entrée. C'est le module R1, à faire avant ou en parallèle. ⏱ 45 h si vous partez de zéro.
CMake — non cité dans les prérequis, mais incontournable dans tout projet C++ scientifique. Savoir écrire un CMakeLists.txt qui compile une bibliothèque, un exécutable et des tests, et qui trouve une dépendance externe. ⏱ 6 h. Ressource : Professional CMake: A Practical Guide de Craig Scott, ou à défaut la documentation officielle et le dépôt cmake-examples.
Python scientifique — NumPy, Matplotlib, pandas. Pour le post-traitement. Le syllabus ne le citait pas pour INPS23 mais le citait pour PRSA24 — prenez-le dès le volet A. ⏱ 6 h si vous connaissez Python.
Un format de données scientifique : HDF5. C'est le standard de fait. Savoir écrire et lire un tableau multidimensionnel en HDF5 depuis C++ et depuis Python, et inspecter un fichier avec h5dump ou h5ls. ⏱ 3 h.
HTML et JavaScript pour la visualisation : suffisant de savoir produire une page avec un graphique. Si vous devez choisir une bibliothèque, Plotly.js ou D3.js. ⏱ 4 h.

Ressources¶

Priorité 1 — la chaîne de développement scientifique¶

Le « Software Carpentry » et le « HPC Carpentry » (carpentries.org) : des leçons courtes et pratiques sur le shell, Git, Make, Python, et une branche HPC sur les ordonnanceurs et le parallélisme. Gratuit, bien construit, exactement au niveau d'INPS23.
Greg Wilson et al., « Best Practices for Scientific Computing » (PLoS Biology, 2014) et « Good Enough Practices in Scientific Computing » (PLoS Computational Biology, 2017). Deux articles courts qui condensent l'essentiel de ce que ce volet veut transmettre. À lire en une heure, à appliquer pendant dix ans.
Victor Eijkhout, Introduction to Scientific Programming, volume de The Art of HPC, PDF gratuit sur theartofhpc.com. Couvre C++ et Fortran orientés calcul scientifique, avec exercices.

Priorité 2 — les outils¶

CMake : documentation officielle, et le livre de Craig Scott.
HDF5 : la documentation du HDF Group, et le tutoriel h5py côté Python. Comprendre aussi NetCDF (qui s'appuie sur HDF5) parce que c'est le format de la météorologie et du climat, donc de WRF.
Sur la reproductibilité : la documentation de Spack (spack.readthedocs.io) et d'EasyBuild. Voir Build et environnement.
Sur la visualisation scientifique : ParaView et VisIt sont les deux outils standards du domaine, tous deux libres et capables de traiter des données distribuées. Savoir charger un fichier, appliquer un filtre et faire une coupe. Matplotlib pour les courbes de performance.

Priorité 3¶

Nicolas Rougier, Scientific Visualization: Python + Matplotlib, libre. Pour produire des figures de qualité publication. La restitution compte autant que le calcul : un résultat qu'on ne sait pas montrer ne vaut rien.
Le Turing Way (the-turing-way.netlify.app), guide communautaire sur la science des données reproductible. Verbeux mais complet.

Exercices¶

E1 · ★ ⏱ 3 h — Le squelette de projet. Créer un projet C++ minimal mais complet : CMakeLists.txt, une bibliothèque, un exécutable, un test unitaire (Catch2 ou GoogleTest), un README, un .gitignore, une licence, et une intégration continue GitLab ou GitHub qui compile et teste. Conservez-le comme modèle : vous le réutiliserez toute votre scolarité.

E2 · ★★ ⏱ 4 h — Écrire et relire proprement. Un programme qui génère un champ 3D de \(256^3\) double et l'écrit :

en texte (ofstream et <<) ;
en binaire brut (fwrite) ;
en HDF5 avec métadonnées (nom du champ, dimensions, unités, date, commit Git du code).

Mesurer la taille des fichiers et le temps d'écriture. Relire les trois depuis Python et vérifier l'identité des données. Le texte doit être environ trois fois plus gros et vingt fois plus lent : c'est la démonstration, une fois pour toutes, qu'on n'écrit pas des résultats scientifiques en ASCII.

E3 · ★★ ⏱ 4 h — La campagne de calcul. Un script (shell ou Python) qui lance le même programme pour une grille de paramètres — par exemple trois tailles de problème, quatre nombres de threads, deux compilateurs — collecte les résultats dans un CSV unique avec toutes les métadonnées, et produit automatiquement trois figures. Contrainte : le script doit être reprenable, c'est-à-dire ne pas relancer les configurations déjà calculées.

E4 · ★★★ ⏱ 6 h — La reproductibilité à l'épreuve. Prendre le projet de E1, en faire une version qui se construit avec Spack ou dans un conteneur (Apptainer ou Docker), et vérifier qu'un camarade peut, à partir du seul dépôt, reproduire une de vos figures au bit près. Documenter les écarts trouvés — il y en aura : version de compilateur, ordre de réduction flottante, graine aléatoire.

E5 · ★★★ ⏱ 5 h — Le tableau de bord. Une page HTML autonome qui charge un CSV de résultats de performance et affiche les courbes de passage à l'échelle de façon interactive (Plotly.js suffit). C'est exactement l'usage du prérequis HTML/JavaScript, et c'est le genre de livrable qui impressionne un jury.

Projet¶

Projet du volet A · La chaîne complète, de l'équation à la figure

⏱ 40 h · ★★★★

Sujet. Choisir un problème physique simple mais non trivial — au choix : diffusion de la chaleur 3D, équation des ondes 2D, dynamique moléculaire de type Lennard-Jones sur quelques milliers de particules, automate de Lattice-Boltzmann pour un écoulement 2D — et construire la chaîne complète.

Les six maillons :

Le code : C++ moderne, structure claire, compilé par CMake, testé. Une validation physique (conservation de l'énergie, solution analytique, symétrie) et non seulement un test qui vérifie que ça ne plante pas.
L'entrée : un fichier de configuration (TOML, YAML ou JSON) et non des constantes codées en dur. Le code doit refuser de tourner si la configuration est invalide, avec un message utile.
La production : un script de campagne qui balaie les paramètres, tourne sous ordonnanceur si vous avez accès à un cluster, écrit des points de reprise (checkpoints) et reprend après interruption.
Les données : sortie HDF5 avec métadonnées complètes, incluant le hash du commit, les options de compilation, la machine et la date.
Le post-traitement : script Python qui produit les figures, et une visualisation 3D avec ParaView ou VisIt.
La restitution : un rapport de dix pages et une présentation de dix minutes. Les compétences de communication étant cotées « Expert », travaillez-la vraiment.

Les trois ajouts qui font la différence, et que l'énoncé officiel ne demandera peut-être pas :

un chiffre de performance : GFLOPS ou mises à jour de cellules par seconde, comparé au pic de la machine et à la bande passante STREAM ;
une courbe de passage à l'échelle si le code est parallèle, ou au moins une étude de l'effet des options de compilation ;
un profil : où passe le temps, obtenu avec perf record ou gprof, avec un commentaire sur le goulot identifié.

Réutilisation. Ce projet est la base du volet B, et le meilleur germe de sujet de PFE. Construisez-le pour durer.

Volet B · La performance des codes réels · ⏱ 35 h¶

L'objectif cité de PRSA24 :

« Des techniques avancées de programmation scientifiques y seront présentées, avec comme exemples d'applications diverses résolutions numériques de problèmes d'algèbre linéaire. Les élèves apprendront à identifier divers problèmes survenant lors de la mise en production de codes réalistes sur des architectures massivement parallèles, et à y apporter des solutions techniques (monitoring, profiling, re-factoring, etc.). Une partie de l'UE sera consacrée au développement et à l'utilisation d'outils de visualisation de données. »

Le sujet d'application — les résolutions numériques de problèmes d'algèbre linéaire — est le bon : c'est là que se concentrent les noyaux dont la performance est bien comprise, mesurable, et comparable à des références (BLAS, LAPACK, ScaLAPACK). Le fond théorique correspondant est dans Solveurs et algèbre linéaire.

Arriver prêt¶

⏱ 20 h. C'est du travail de technique appliquée : si vous passez le temps disponible à installer des outils, vous n'apprenez rien. Installez avant.

Savoir profiler. Maîtriser perf record / perf report, savoir lire un graphe d'appel, produire un flame graph. ⏱ 6 h. Voir Outils de mesure.
Connaître BLAS et LAPACK. Savoir ce que fait dgemm, dgemv, daxpy, dgesv, dsyev, et la distinction cruciale entre niveau 1 (vecteur, limité par la mémoire), niveau 2 (matrice-vecteur, limité par la mémoire) et niveau 3 (matrice-matrice, limité par le calcul). ⏱ 5 h. Voir Solveurs.
Python scientifique : NumPy, SciPy, Matplotlib, et savoir appeler du C++ depuis Python (pybind11 ou ctypes). ⏱ 5 h.
Un outil de visualisation : ParaView ou VisIt, au niveau « je sais charger un fichier, appliquer une coupe et exporter une image ». ⏱ 4 h.

Ressources¶

Priorité 1 — l'ingénierie de performance¶

Georg Hager, Gerhard Wellein, Introduction to High Performance Computing for Scientists and Engineers, CRC Press. Le livre de ce volet. Il traite, dans cet ordre : l'architecture moderne, l'optimisation séquentielle, l'analyse de performance, les modèles simples de performance, OpenMP, MPI, et l'optimisation hybride. Le tout avec une rigueur de mesure exemplaire. Si vous ne lisez qu'un livre de HPC dans votre vie, c'est celui-là.
Le cours MIT 6.172 Performance Engineering of Software Systems, sur OpenCourseWare, par Charles Leiserson et Julian Shun. Vidéos, notes et devoirs gratuits. La meilleure formation existante à l'optimisation de code, avec des devoirs chronométrés qui forcent à mesurer.
Le blog de Georg Hager (blogs.fau.de/hager) : des études de cas d'optimisation réelles, avec mesures. C'est la lecture la plus formatrice qui existe sur l'ingénierie de performance en HPC.

Priorité 2 — le profilage et l'analyse¶

Brendan Gregg, Systems Performance, 2ᵉ éd., et son site (brendangregg.com). L'inventeur des flame graphs. Le livre couvre la méthodologie de diagnostic de performance système : c'est la méthode qui manque à la plupart des ingénieurs.
La documentation de LIKWID (github.com/RRZE-HPC/likwid) : likwid-perfctr pour les compteurs matériels, likwid-bench pour les micro-bancs d'essai, likwid-topology pour la topologie. Développé par l'équipe de Hager, pensé pour le HPC.
Intel VTune et Intel Advisor. Advisor produit directement un diagramme roofline avec vos boucles positionnées dessus : c'est l'outil le plus pédagogique du domaine. Gratuit dans oneAPI.
HPCToolkit, Score-P avec Cube et Vampir, TAU, Extrae avec Paraver, et MAQAO (maqao.org, développé à l'université de Versailles Saint-Quentin, donc français et proche de vous). MAQAO fait de l'analyse statique et dynamique de boucles, avec un rapport qui dit explicitement pourquoi une boucle n'est pas vectorisée.

Priorité 3 — la visualisation¶

ParaView (paraview.org) : le tutorial officiel et le ParaView Guide. Sait lire du VTK, du HDF5, du NetCDF, et tourne en parallèle sur un cluster.
VisIt (Lawrence Livermore) : l'alternative, avec une philosophie voisine.
Le format VTK et la bibliothèque vtk, pour écrire directement des sorties visualisables depuis un code C++.
Nicolas Rougier, Scientific Visualization: Python + Matplotlib, libre, pour les figures de qualité publication.

Exercices¶

E1 · ★★ ⏱ 3 h — Le flame graph. Prendre un code de calcul de plus de mille lignes que vous n'avez pas écrit. Le profiler avec perf record -g, produire un flame graph, et répondre par écrit : quelles sont les trois fonctions les plus coûteuses, quelle fraction du temps total représentent-elles, et laquelle optimiseriez-vous en premier et pourquoi ?

E2 · ★★ ⏱ 3 h — Compute bound ou memory bound ? Pour trois noyaux — un DGEMM, un DAXPY, un SpMV — calculer l'intensité arithmétique (nombre d'opérations flottantes par octet transféré depuis la mémoire), la placer sur le roofline de la machine, prédire le régime, puis vérifier par mesure avec likwid-perfctr -g MEM_DP ou perf stat sur les compteurs adéquats. Lien : Modèles de performance.

E3 · ★★ ⏱ 2 h — BLAS niveau 1, 2, 3. Mesurer les GFLOPS de daxpy, dgemv et dgemm d'OpenBLAS sur des données de même volume total. Constater que seul le niveau 3 approche le pic de la machine, et expliquer par le rapport opérations/octets : \(O(n)\) opérations pour \(O(n)\) données au niveau 1, \(O(n^2)\) pour \(O(n^2)\) au niveau 2, \(O(n^3)\) pour \(O(n^2)\) au niveau 3. C'est l'observation qui structure tout l'algorithmique numérique haute performance : on reformule les algorithmes pour les exprimer en BLAS 3.

E4 · ★★★ ⏱ 5 h — Le refactoring mesuré. Prendre un code lent et le refactorer en cinq étapes, en mesurant après chacune : suppression des allocations dans la boucle chaude, changement de disposition des données, élimination des recalculs, vectorisation, parallélisation. Tenir un tableau. Contrainte : les tests doivent passer après chaque étape.

E5 · ★★★ ⏱ 4 h — La surveillance en direct. Instrumenter un long calcul pour qu'il publie sa progression et ses métriques (itération courante, résidu, temps par itération, mémoire utilisée, puissance électrique si accessible) dans un fichier ou vers Prometheus, et construire un tableau de bord qui l'affiche en temps réel. C'est le sens du mot « monitoring » de l'objectif cité, et c'est directement ce que fait une équipe pendant les quarante-huit heures.

E6 · ★★★★ ⏱ 6 h — Reproduire un résultat publié. Choisir un article court d'optimisation HPC — le blog de Hager en contient plusieurs, ou un article des actes d'une conférence — et reproduire une de ses figures sur votre machine. Vous n'obtiendrez pas les mêmes chiffres (machine différente) mais vous devriez obtenir la même forme de courbe. Si ce n'est pas le cas, comprendre pourquoi est l'exercice.

Projet¶

Projet du volet B · L'expertise complète d'un code de production

⏱ 45 h · ★★★★

Sujet. Choisir une application scientifique libre, réelle et non triviale, et produire un rapport d'expertise de performance complet, avec des améliorations implémentées et mesurées.

Candidats, choisis pour être compilables et documentés :

Code	Domaine	Langage	Intérêt
GROMACS	Dynamique moléculaire	C++, CUDA	Extrêmement optimisé : le défi est de comprendre pourquoi il est rapide
LAMMPS	Dynamique moléculaire	C++	Modulaire, facile à instrumenter
OpenFOAM	Mécanique des fluides	C++	Notoirement mauvais en E-S : beaucoup à gagner
Code_Saturne	Mécanique des fluides	C, Fortran	Français, EDF, bien documenté
WRF	Météorologie	Fortran	Au programme de la SCC de SC26
MFC	Écoulements multiphasiques	Fortran	Au programme de la SCC de SC26
HPCG	Benchmark	C++	Petit, lisible, représentatif

Les deux dernières lignes méritent attention : WRF et MFC sont les applications scientifiques annoncées pour la Student Cluster Competition de SC26. Travailler sur l'une d'elles en projet d'UE, c'est préparer la compétition en étant noté pour cela.

Les huit parties du rapport :

Description du code et du cas test. Que calcule-t-il, quelles équations, quelles tailles de problème représentatives.
Construction reproductible. La recette exacte, idéalement en Spack ou en conteneur. Consigner les versions de tout.
Mesure de référence. Temps, répartition calcul/communication/E-S, avec trois répétitions et la variance.
Modèle de performance. Intensité arithmétique, position sur le roofline, borne théorique. Avant de profiler : c'est la prédiction.
Profil. Points chauds avec perf ou VTune, profil MPI avec mpiP ou Score-P, profil d'E-S avec Darshan. Confronter au modèle.
Passage à l'échelle. Strong et weak scaling, avec identification du point où l'efficacité tombe sous 70 % et explication de la cause.
Améliorations. Au moins trois, chacune avec hypothèse chiffrée, implémentation, mesure, et écart entre prédiction et résultat. Les améliorations qui ne marchent pas sont aussi intéressantes que celles qui marchent, à condition d'expliquer pourquoi.
Visualisation des résultats scientifiques avec ParaView, pour vérifier que les améliorations n'ont rien cassé physiquement.

Critère de réussite : le rapport doit être utilisable par quelqu'un qui veut faire tourner ce code sur une machine similaire. C'est-à-dire qu'il doit contenir des recommandations opérationnelles, pas seulement des mesures.

Réutilisation : ce rapport est une pièce maîtresse d'un dossier de candidature à une compétition, et la matrice d'un rapport de PFE.

Erreurs fréquentes¶

Cinq fautes de chaîne

Les paramètres codés en dur. Un code dont il faut recompiler pour changer la taille de la grille est inutilisable en campagne. C'est la première chose qu'un jury ou un encadrant remarque.
L'absence de métadonnées. Un fichier de résultats sans la version du code qui l'a produit est une donnée perdue. Dans six mois, vous ne saurez plus la reproduire. Écrivez le hash Git dans chaque fichier de sortie : trois lignes de CMake suffisent.
Les résultats en ASCII. Voir E2. Cent fois plus gros, vingt fois plus lent, et une perte de précision en écriture.
Le post-traitement à la main. Si une figure demande dix clics dans un tableur, elle sera fausse à la troisième régénération. Tout doit être scripté, y compris les figures du rapport.
Mesurer le temps total au lieu du temps de calcul. Un programme dont le démarrage prend 3 secondes et le calcul 0,2 seconde mesure surtout le démarrage. Instrumentez les phases séparément dès le début.

Sept fautes de méthode en ingénierie de performance

Optimiser avant de mesurer. Le point chaud n'est presque jamais là où l'intuition le place. La règle est absolue : profiler d'abord.
Mesurer avant de modéliser. Erreur symétrique et plus subtile. Sans borne théorique, on ne sait pas si 40 GFLOPS est bon ou catastrophique. Calculez le roofline avant de profiler : vous saurez alors s'il reste quelque chose à gagner.
Optimiser une fonction qui prend 3 % du temps. La loi d'Amdahl s'applique aussi à l'optimisation : accélérer infiniment une fraction \(f\) du temps total ne peut gagner plus que \(1/(1-f)\).
Changer deux choses à la fois. Si vous vectorisez et changez la disposition mémoire dans le même commit, et que le résultat est plus lent, vous ne saurez pas laquelle des deux est responsable. Une modification, une mesure, un commit.
Ne pas valider numériquement après optimisation. Un code deux fois plus rapide qui donne un résultat faux est un code cassé. La vectorisation et le changement d'ordre des réductions modifient les arrondis : il faut une tolérance justifiée, pas une comparaison exacte.
Mesurer sur une machine partagée sans le dire. Toutes vos mesures auront 20 % de variance, et vos conclusions seront du bruit. Utilisez --exclusive, ou signalez honnêtement la variance.
Présenter un facteur d'accélération sans la référence. « Deux fois plus rapide » n'a de sens que par rapport à quelque chose. Deux fois plus rapide qu'une version délibérément naïve n'est pas un résultat.

Où ce module s'insère¶

Se relie à	Comment
R1 · C++ pour le calcul	Le langage que ce module met en chaîne
R3 · Cluster et Slurm	Le volet B suppose « Linux administrateur » : c'est R3
R4 · Stockage parallèle	Les données que la chaîne produit
Outils de mesure	Le catalogue complet du profilage, à ne pas dupliquer ici
Solveurs et algèbre linéaire	Le fond numérique du volet B
ITIC23 et DEVO35	Les deux modules FISA qui recoupent partiellement la reproductibilité
PRFE36	Le débouché naturel : ce module est un sujet de PFE

À retenir¶

R2 en quatre phrases

C'est le plus gros trou de la maquette FISA : aucune UE n'enseigne le calcul scientifique, ni sa chaîne de production, ni la remise en performance d'un code existant.

Le volet A construit la chaîne — build reproductible, campagne de calcul, format de données, post-traitement, visualisation. Le volet B la met à l'épreuve d'un code réel — profilage, diagnostic, refactoring, mesure.

Les deux volets doivent porter sur le même code, et ce code doit venir de votre entreprise : c'est ce qui transforme 80 heures de travail personnel en livrable professionnel.

Le contenu d'origine n'étant pas publié, ce module vaut ce que vous en faites. Décidez dès le départ d'y ajouter les trois choses qu'aucun énoncé ne demandera : une mesure chiffrée, une construction reproductible, une étude de passage à l'échelle.

Module suivant : R3 · Cluster et Slurm.