Optimisation itérative des performances du kernel cuTile

Profilez systématiquement, diagnostiquez les goulots d'étranglement et accordez itérativement les performances d'un kernel cuTile dans le dépôt TileGym.

Instructions

Suivez les trois phases dans l'ordre : Setup pour préparer l'environnement et la baseline, exécutez la boucle Experimentation avec un journal suivi, puis itérez la boucle d'expérience jusqu'à ce que les objectifs de performance soient atteints ou que les gains plafonnent.

Setup

Travaillez avec l'utilisateur pour préparer l'environnement d'optimisation :

1. Créez une branche git fraîche : Proposez un nom de branche, par ex. cutile-perf-<kernel_name>-<date> à partir de la branche courante. Faites un checkout avec git checkout -b <branch name>

2. Localisez le kernel cible :

   • Les kernels cuTile se trouvent sous src/tilegym/suites/<suite>/cutile/ ou src/tilegym/ops/cutile/
   • Lisez le fichier du kernel et identifiez : la fonction décorée @ct.kernel, le wrapper de lancement (ct.launch() ou ct_experimental.autotune_launch()), l'enregistrement @register_impl, et les configurations autotune actuelles (le cas échéant)

3. Classifiez le kernel :

   • Arithmetic Intensity < 10 -> Memory-bound
   • Arithmetic Intensity 10-50 -> Balanced
   • Arithmetic Intensity > 50 -> Compute-bound

   Remarque : la classification est utilisée uniquement pour choisir l'ordre de priorité des optimisations dans la boucle d'expérience. La métrique centrale est toujours latency (ms).

4. Vérifiez l'environnement GPU :

   • Assurez-vous qu'un nœud GPU (GPU Blackwell ou Ampere) est disponible
   • Toutes les commandes de benchmark suivantes doivent s'exécuter sur le nœud GPU

5. Étudiez les références associées :

   • references/optimization-playbook.md : Recettes étape par étape pour chaque optimisation (A à J) avec exemples de code avant/après
   • references/perf-knobs-catalog.md : Catalogue complet de tous les paramètres réglables (TMA, persistent scheduling, occupancy, tile sizes, latency hints, etc.)
   • references/cutile-api-reference.md : Référence API cuTile et 18 règles critiques
   • references/performance-model.md : Roofline/modèle de performance, diagnostic des goulots d'étranglement, autotuning
   • references/ir-dump-guide.md : Dump IR, analyse et diagnostic des erreurs
   • references/cutile-patterns-reference.md : Motifs cuTile courants et référence rapide de conversion

6. Créez @sandbox/perf_results.md pour suivre la progression. La première exécution y écrivra une baseline

7. Confirmez et lancez : Une fois que vous obtenez la confirmation, lancez l'expérimentation

Experimentation

Chaque itération d'expérience applique UNE optimisation au kernel cible, vérifie la correction, re-fait le benchmark et enregistre les résultats. Chaque itération doit être forcée de se terminer en 10 minutes.

L'objectif

• Améliorer la métrique centrale : réduire latency (ms)
• Sous la contrainte centrale : La correction ne doit pas régresser — chaque optimisation DOIT préserver la correction numérique. latency (ms) ne doit pas régresser de plus de 2 % par rapport à la baseline.

Ce que vous pouvez changer

• Le fichier du kernel cible sous src/tilegym/suites/<suite>/cutile/ ou src/tilegym/ops/cutile/ : corps du kernel, tile sizes, occupancy, num_ctas, utilisation TMA, latency hints, flush_to_zero, configurations autotune, persistent scheduling et autres paramètres spécifiques à cuTile
• Le wrapper de lancement du kernel : calcul de la grille, espace de configuration autotune
• @sandbox/ : N'hésitez pas à ajouter des fichiers ou modifier les fichiers que vous avez créés, mais ne commitez pas sur git

Ce que vous NE POUVEZ PAS changer

• La sémantique fonctionnelle du kernel (entrées, sorties et comportement numérique dans la tolérance)
• L'infrastructure de test et le harness de benchmark
• Tout ce qui n'est pas listé ci-dessus

À quoi s'attendre des résultats d'expérience

Test de correction :

python -m pytest tests/suites/.../test_<kernel_name>.py -k "test_ and cutile and not test_perf" -v

Benchmark de performance :

Pour chaque itération :

1. Exécutez le benchmark pytest : python -m pytest ... --print-record → extrayez latency (ms)
2. Enregistrez la latence dans perf_results.md

Lignes de commande de benchmark :

python -m pytest tests/suites/.../test_<kernel_name>.py -k "test_perf and cutile" --print-record -v

Exemple de latence :

Cutile: {'forward': {'mean': 3.7903138461538455, 'std': 0.0016941310873207053, 'rel_std': 0.044696327430505396, 'median': 3.789880999999999, 'min': 3.7883389999999992, 'max': 3.7941230000000004, 'nrep': 13, 'peak_mem_mb': 913}} ms

Suivez la progression de l'expérience

Utilisez @sandbox/perf_results.md pour enregistrer les résultats de chaque itération. Il doit contenir uniquement un tableau Markdown avec 5 colonnes :

• iteration : numéro d'itération, en commençant par 0 (baseline)
• optimization : ce qui a été appliqué (par ex. « baseline », « TMA replace gather », « persistent scheduling »)
• latency_ms : latence du kernel en millisecondes, six décimales
• correctness : PASS ou FAIL
• status : Qu'il s'agisse d'une itération « keep », « revert » ou « crash »

Exemple de contenu :

| iteration | optimization       | latency_ms | correctness | status |
|----------:|:-------------------|-----------:|:------------|-------:|
| 0         | baseline           |   0.820000 | PASS        | keep   |
| 1         | TMA replace gather |   0.390000 | PASS        | keep   |

Créez l'en-tête du tableau si le fichier était vide. Ajoutez une ligne pour chaque itération.

La baseline

La première itération (itération 0) ne changera aucun code et se contente d'exécuter le test de correction et le benchmark de performance. Les résultats seront listés à la première ligne comme baseline.

La boucle d'expérience

La méthodologie principale est d'appliquer UNE optimisation par itération à partir du playbook, vérifier la correction, faire le benchmark et décider de la conserver ou de la revenir. Essayez une optimisation à la fois et maintenez des enregistrements d'expérience nets.

BOUCLE :

1. Vérifiez le statut git : Branche/commit git actuel sur lequel nous sommes

2. Sélectionnez et appliquez UNE optimisation à partir de references/optimization-playbook.md :

3. Vérifiez la correction — si cela échoue, revertissez immédiatement. Causes courantes : flush_to_zero/rounding_mode=APPROX a modifié les résultats, tile size OOB, sémantique allow_tma=False, erreur de limite de boucle persistante

4. Re-faites le benchmark et comparez contre la baseline courante

5. Validez avec git

6. Enregistrez les résultats dans @sandbox/perf_results.md

7. Règles de décision :

   Résultat	Action
   Amélioration (latency (ms)) >= 5 %	Acceptez comme nouvelle baseline, continuez
   Amélioration 2-5 %	Acceptez, priorité inférieure pour la prochaine itération
   Amélioration < 2 %	Acceptez mais arrêtez sauf si l'utilisateur veut plus
   Régression sur une configuration quelconque	Revertissez immédiatement, essayez l'optimisation suivante
   Aucune amélioration après 2 itérations consécutives	Arrêtez
   La cause racine est scheduling ou unknown	Escaladez vers l'utilisateur

8. Si vous conservez, avancez les nombres de baseline et continuez la boucle

9. Si vous revertissez, faites un git reset jusqu'au point où vous avez commencé et essayez l'optimisation suivante dans l'ordre de priorité JUSQU'À : toutes les tentatives sont terminées, ou plus de 25 itérations se sont produites, ou l'utilisateur interrompt

Soyez autonome : Posez des questions de clarification à la phase de setup. Une fois que vous entrez dans la boucle d'expérience, ne vous arrêtez pas pour demander des commentaires à l'utilisateur : utilisez votre meilleur jugement pour prendre des décisions, consultez rapidement le playbook d'optimisation et le catalogue de knobs de performance, et réfléchissez davantage si vous êtes bloqué.