What Irregularity Costs: CUDA C++, Rust, and Triton on a Hash-Blocked GPU Workload

La Scène et les Acteurs

Imaginez que vous essayiez de construire un modèle 3D d'une pièce à l'aide d'un appareil photo qui prend des milliers de clichés. Pour y parvenir, votre ordinateur doit organiser une quantité massive de données sur chaque minuscule fragment d'espace dans cette pièce. C'est le monde de la programmation GPU, où les « GPU » sont les puces graphiques ultra-rapides à l'intérieur des ordinateurs, également brillantes pour effectuer des millions de calculs mathématiques à la fois.

Habituellement, lorsque les gens comparent différents langages de programmation pour ces puces, ils les testent sur des tâches très nettes et prévisibles, comme la multiplication de gigantesques grilles de nombres. C'est comme tester une voiture de course sur une autoroute parfaitement droite et déserte. Chaque voie est identique et chaque conducteur sait exactement combien de temps durera la course. Mais le monde réel est désordonné. Dans des applications comme la réalité virtuelle ou la navigation de robots, l'ordinateur doit gérer des données chaotiques et imprévisibles. C'est comme envoyer cette même voiture de course dans une rue citadine sinueuse et encombrée, où les embouteillages surviennent de manière aléatoire et où les conducteurs doivent s'arrêter et repartir constamment. Cet article pose une question simple mais cruciale : quand la route devient désordonnée, est-ce que tous les langages de programmation performent de la même manière, ou certains restent-ils coincés dans le trafic pendant que d'autres foncent à travers ?

Le Grand Duel des Langages GPU

Dans cette étude, des chercheurs ont pris trois façons populaires de communiquer avec ces super-puces — CUDA C++ (le standard classique écrit à la main), Rust (un langage moderne connu pour sa sécurité) et Triton (un outil plus récent conçu pour faciliter le codage) — et les ont mis au travail sur une tâche très spécifique et chaotique : la construction d'une carte 3D d'une pièce en utilisant une « table de hachage » (hash table).

Considérez une table de hachage comme un vestiaire géant et chaotique. Vous avez des milliers de personnes (points de données) essayant de trouver un casier (un emplacement en mémoire) pour y ranger leurs affaires. Parfois, le casier qu'elles veulent est vide, elles le prennent donc. Mais souvent, le casier est déjà occupé, elles doivent alors vérifier le suivant, puis le suivant, jusqu'à ce qu'elles trouvent un espace libre. Dans un monde parfait, tout le monde trouve un casier instantanément. Dans ce travail « irrégulier », certaines personnes trouvent un casier immédiatement, tandis que d'autres doivent chercher longtemps, et tout le monde se dispute les mêmes quelques casiers en même temps.

Les chercheurs ont exécuté exactement le même travail sur les trois langages et ont mesuré la rapidité avec laquelle ils l'ont terminé. Les résultats ont été un choc : les langages se sont comportés de manière totalement différente selon le type de travail.

La Partie « Régulière » : Une Égalité Parfaite

D'abord, ils ont testé la partie « régulière » du travail, qui consiste à marcher dans un couloir et à peindre chaque mur que l'on voit. Cette partie est prévisible. Sur cette tâche, les trois langages étaient presque identiques. Que vous utilisiez le vieux CUDA, le moderne Rust ou le facile à utiliser Triton, ils ont terminé à peu près dans le même laps de temps. Si vous ne regardiez que ces tests nets et prévisibles (ce que font la plupart des autres études), vous penseriez qu'il n'importe pas de choisir son langage.

La Partie « Irrégulière » : La Grande Fracture

Ensuite, ils ont testé la partie « irrégulière » : la recherche chaotique dans le vestiaire. C'est là que l'histoire change radicalement.

• Rust vs CUDA C++ : Le langage Rust a performé presque aussi bien que le hand-written CUDA C++. Il était juste un tout petit peu plus lent (environ 1 % à 3 % dans certains cas), ce qui équivaut pratiquement à une égalité. Rust a prouvé qu'il pouvait gérer le trafic désordonné et imprévisible aussi bien que le vétéran.
• La Lutte de Triton : Triton, cependant, s'est heurté à un mur massif. Sur la tâche de recherche chaotique, il était plus de 10 fois plus lent que les deux autres. Dans certains tests réels avec de véritables scans de pièces, il était presque 30 fois plus lent.

Pourquoi Triton s'est-il Coincé ?

Les chercheurs ne se sont pas contentés de dire « Triton est lent » ; ils ont découvert précisément pourquoi il était bloqué, et ce n'était pas parce que le code était mal écrit. C'était dû à la façon dont le langage est construit.

Imaginez que Triton soit un professeur strict qui exige que chaque élève reste assis à sa place pendant un temps fixe, même s'il termine son travail plus tôt. Dans le vestiaire chaotique, certains fils (élèves) trouvent un casier en une seconde, tandis que d'autres en mettent dix.

• Le Problème : Triton force les fils rapides à attendre dans une boucle jusqu'à ce que le fil le plus lent ait terminé, même s'ils n'ont plus rien à faire. C'est comme une course où le vainqueur doit rester immobile et attendre que la dernière personne franchisse la ligne d'arrivée avant que quiconque puisse quitter la piste.
• Le Problème du « Masque » : De plus, Triton manque d'un outil spécifique (appelé « masque ») qui permet aux fils rapides de s'arrêter complètement de travailler. Au lieu de cela, ils doivent continuer à exécuter une tâche fictive, gaspillant de l'énergie et encombrant le système. Les chercheurs ont découvert que ce choix de conception forçait l'ordinateur à effectuer une quantité massive de travail inutile, ralentissant tout de 10 à 30 fois.
• Un Danger Caché : Il y avait également un problème de sécurité. Parce que Triton impose une limite de temps fixe à la recherche, si le vestiaire devient trop encombré, la recherche peut abandonner et cesser de chercher. Cela signifie que l'ordinateur supprime silencieusement des parties de la pièce 3D, créant des trous invisibles dans le modèle final. Les chercheurs ont constaté qu'à certains niveaux d'encombrement, Triton perdait des pans entiers de la surface, alors que les autres langages les trouvaient parfaitement.

Pourquoi Rust était un Peu Plus Lent (Le Piège Invisible)

Rust était très proche de la victoire, mais il n'était pas tout à fait aussi rapide que le code CUDA écrit à la main. Les chercheurs ont passé beaucoup de temps à essayer de comprendre pourquoi, vérifiant le nombre d'instructions et la mémoire utilisée. Ils ont découvert que Rust faisait en réalité moins de travail que CUDA, et pourtant, il était plus lent.

Le coupable était un piège caché dans la gestion de la sécurité de Rust. Rust possède une fonctionnalité qui rend la lecture de données partagées « sûre » en garantissant que tout le monde voit la même version. Cependant, sur ces puces spécifiques, la méthode « sûre » de lecture des données force l'ordinateur à sauter sa mémoire cache la plus rapide pour passer à une plus lente. C'est comme un agent de sécurité qui insiste pour vérifier chaque colis à l'entrée, même si les colis sont déjà connus comme étant sûrs. Cette étape supplémentaire a ralenti Rust d'environ 20 à 30 %, mais c'était un prix infime à payer par rapport au ralentissement massif de Triton.

La Conclusion

La principale leçon de cet article est que vous ne pouvez pas juger un langage de programmation simplement par sa performance sur des tâches nettes et prévisibles.

Si vous ne faites des tests que sur l'autoroute « régulière », Rust, CUDA et Triton ressemblent tous à des champions. Mais une fois que vous les jetez dans le trafic urbain « irrégulier » de la cartographie 3D réelle, les résultats divergent radicalement.

• Rust est un sérieux prétendant, restant presque aussi rapide que le meilleur code écrit à la main.
• Triton, bien qu'excellent pour les tâches ordonnées, lutte énormément avec le travail chaotique et imprévisible, devenant des dizaines de fois plus lent et pouvant perdre des données sans que personne ne s'en aperçoive.

Les chercheurs concluent que pour les tâches impliquant des données réelles et désordonnées, choisir le mauvais langage n'est pas seulement un petit inconvénient ; cela peut rendre votre programme inutilisable ou le faire échouer silencieusement. Ils ont également découvert que de nombreuses études précédentes ont manqué cela car elles ne testaient que les parties « régulières », laissant les parties dangereuses et désordonnées inexplorées.