4 · Projets¶
Le HPC ne s'apprend pas en lisant. Le seul retour d'information fiable est le chronomètre, et il est impitoyable : un code est rapide ou il ne l'est pas, et aucune argumentation ne change le chiffre.
Cette partie propose une progression de quinze projets, du premier produit matriciel mesuré jusqu'au mini-cluster complet avec ordonnanceur et benchmarks.
Comment cette partie est organisée¶
| Niveau | Chapitre | Nombre | Charge totale | Quand |
|---|---|---|---|---|
| Fondateurs | 01 | 5 | ≈ 60 h | 1A et été avant le S3 |
| Intermédiaires | 02 | 5 | ≈ 140 h | Pendant le S3 et le S4 |
| Avancés | 03 | 5 | ≈ 220 h | S4, S5, et RDEV36 |
Et un chapitre de méthode : Comment choisir, qui donne la grille de sélection et de planification. Lisez-le avant de vous lancer : le catalogue complet représente plus de quatre cents heures, ce qui n'est pas réalisable en plus des cours.
Les règles communes à tous les projets¶
Ce sont elles qui font la différence entre un projet qui vous apprend quelque chose et un projet qui vous occupe.
Les sept règles
1. Un dépôt Git par projet, dès la première ligne. Avec un README qui
explique comment construire et comment mesurer.
2. Une borne avant une mesure. Calculez ce que la machine peut faire avant de mesurer ce que votre code fait. Voir Modèles de performance.
3. Un test de validation qui échoue si le résultat est faux. L'optimisation casse les codes. Sans test, vous produirez un code rapide et faux, et vous ne le saurez pas.
4. Une mesure consignée par étape. Date, machine, compilateur, options, paramètres, métrique, hash du commit. Dans un CSV ou une base, pas dans votre mémoire.
5. Une modification à la fois. Sinon vous ne saurez pas ce qui a marché.
6. Les échecs consignés aussi. « J'ai essayé le blocking à deux niveaux, cela n'a rien apporté, voici pourquoi » est une information plus précieuse qu'un succès, et c'est ce que personne ne note.
7. Un livrable lisible par un autre. Un tableau des étapes avec les gains, et trois paragraphes de conclusion. Si vous ne pouvez pas l'expliquer, vous ne l'avez pas compris.
La métrique de progression¶
Un moyen simple de savoir où vous en êtes. Pour chaque projet, calculez le rapport entre votre performance et la borne théorique.
| Rapport à la borne | Interprétation |
|---|---|
| Moins de 5 % | Version naïve, ou un problème identifiable |
| 5 à 20 % | Première optimisation faite |
| 20 à 50 % | Travail sérieux |
| 50 à 80 % | Niveau professionnel |
| Plus de 80 % | Niveau bibliothèque optimisée |
Le but n'est pas d'atteindre 80 % partout : c'est très coûteux, et sur certains noyaux c'est impossible. Le but est de savoir où vous êtes et pourquoi.
Ce que ces projets valent en dehors de l'apprentissage¶
Trois usages concrets, à garder en tête pour ne pas les négliger.
1. Le dossier de candidature à une compétition. Un dépôt public avec cinq projets mesurés et documentés vaut plus que n'importe quelle lettre de motivation. Voir Éligibilité et candidature.
2. L'entretien d'embauche. La question « parlez-moi d'un code que vous avez optimisé » est posée systématiquement dans ce domaine. Une réponse appuyée sur un tableau de mesures met fin à l'entretien technique par l'affirmative.
3. Les projets d'UE et RDEV36. Plusieurs de ces projets sont conçus pour recouvrir un projet noté. C'est une optimisation de votre emploi du temps, pas de la triche : le travail est réel, il compte simplement deux fois.
Les quinze projets, en un coup d'œil¶
Fondateurs — chapitre 01¶
| N° | Projet | ⏱ | ★ |
|---|---|---|---|
| P1 | Le produit matriciel, du naïf à OpenBLAS | 15 h | ★★★ |
| P2 | La caractérisation complète d'une machine | 12 h | ★★ |
| P3 | Le stencil 2D, séquentiel puis OpenMP | 10 h | ★★ |
| P4 | Le chronomètre et le carnet de mesures | 8 h | ★★ |
| P5 | La chaîne de développement scientifique complète | 15 h | ★★★ |
Intermédiaires — chapitre 02¶
| N° | Projet | ⏱ | ★ |
|---|---|---|---|
| P6 | Le solveur de Poisson distribué en MPI | 35 h | ★★★★ |
| P7 | Le cluster maison, du métal au HPL | 35 h | ★★★★ |
| P8 | L'expertise de performance d'un code réel | 30 h | ★★★★ |
| P9 | Le portage sur GPU d'un noyau, cinq manières | 25 h | ★★★★ |
| P10 | La bibliothèque de threads utilisateur | 15 h | ★★★★ |
Avancés — chapitre 03¶
| N° | Projet | ⏱ | ★ |
|---|---|---|---|
| P11 | Le banc d'essai complet de compétition | 50 h | ★★★★ |
| P12 | L'optimisation d'un entraînement distribué | 40 h | ★★★★ |
| P13 | La refonte des entrées-sorties d'un code de production | 35 h | ★★★★ |
| P14 | Le simulateur de circuits quantiques haute performance | 40 h | ★★★★ |
| P15 | L'étude de performance publiable | 40 h | ★★★★ |
Chapitre suivant : Projets fondateurs.