Partie 3 · Performance¶
Savoir écrire un noyau correct est une chose. Savoir s'il est bon en est une autre, et c'est celle-là qui distingue un ingénieur GPU.
Le principe directeur¶
Il n'y a qu'une seule question à poser à un noyau :
Quelle ressource est saturée, et à quel pourcentage ?
Tant que vous ne savez pas y répondre, toute optimisation est du bricolage. La réponse s'obtient en deux minutes avec le modèle roofline, et se raffine avec un profileur.
Cette partie enseigne dans l'ordre :
- comment prédire la performance d'un noyau avant de l'écrire ;
- comment mesurer ce qu'il fait réellement ;
- comment interpréter l'écart entre les deux.
Ce que vous allez apprendre¶
- Calculer l'intensité arithmétique d'un noyau et en déduire sa borne supérieure de performance.
- Reconnaître, dans le code source, les motifs qui gaspillent la bande passante.
- Comprendre pourquoi viser 100 % d'occupancy est une erreur, et ce qu'il faut viser à la place.
- Lire un rapport Nsight Compute : Speed of Light, Memory Workload Analysis, Warp State Statistics.
- Appliquer une checklist ordonnée par rendement décroissant.
Ordre de lecture¶
1 · Le modèle roofline¶
Le chapitre le plus rentable du document. Trois lignes de calcul qui vous disent si votre noyau peut aller plus vite et par quel levier.
2 · Coalescence et conflits de banc¶
Les deux façons de gaspiller de la bande passante sans s'en apercevoir. Avec les motifs à reconnaître et les remèdes.
3 · Occupancy et latence¶
La loi de Little appliquée au GPU, pourquoi Volkov a démontré en 2010 qu'il faut parfois baisser l'occupancy, et comment décider.
4 · Profilage avec Nsight¶
Nsight Systems pour la chronologie, Nsight Compute pour le noyau. Quelles sections lire, dans quel ordre, et comment ne pas se noyer sous 200 métriques.
5 · Checklist d'optimisation¶
La liste opérationnelle, ordonnée par rendement décroissant, avec pour chaque point le symptôme qui le déclenche.
La méthode en une image¶
┌─────────────────────────────────────────────────────────────┐
│ 1. CALCULER : intensité arithmétique I = ops / octets │
│ seuil machine I_crit = P / B │
│ → limité par mémoire ou par calcul ? │
├─────────────────────────────────────────────────────────────┤
│ 2. BORNER : t_min = octets / B (si mémoire) │
│ t_min = ops / P (si calcul) │
├─────────────────────────────────────────────────────────────┤
│ 3. MESURER : t_reel avec des événements CUDA │
├─────────────────────────────────────────────────────────────┤
│ 4. COMPARER : t_reel / t_min │
│ < 1,2 → arrêter, c'est bon │
│ 1,2-2 → optimisations fines │
│ > 2 → il y a un problème structurel │
├─────────────────────────────────────────────────────────────┤
│ 5. PROFILER : Nsight Compute pour savoir lequel │
└─────────────────────────────────────────────────────────────┘
Le réflexe à acquérir
Avant d'ouvrir un profileur, faites l'étape 1 au papier. Elle prend deux minutes, elle est juste à 20 % près, et elle vous dit si vous cherchez au bon endroit. Beaucoup d'ingénieurs passent des journées à optimiser le calcul d'un noyau qui est limité par la mémoire depuis le début.
Un avertissement sur les chiffres¶
Les mesures de ce document ne sont pas des reproductions
Les chiffres de performance cités dans cette partie proviennent des sources indiquées (documentations, papiers, blogs des équipes concernées). Ils n'ont pas été reproduits dans l'environnement de rédaction, qui ne dispose pas de GPU.
Les calculs d'intensité arithmétique et de bornes, en revanche, sont de l'arithmétique élémentaire refaisable au papier — et c'est justement leur intérêt : vous n'avez besoin de faire confiance à personne pour les vérifier.