NVIDIA ajoute enfin la prise en charge native de Python à CUDA

• Après des années où la boîte à outils CUDA de NVIDIA était centrée sur C/C++, la prise en charge native de Python a été officiellement ajoutée lors de la GTC 2024
• Il est désormais possible d’exécuter directement sur GPU des calculs rapides centrés sur les algorithmes en utilisant uniquement Python
• L’architecte CUDA Stephen Jones explique que « Python CUDA n’est pas simplement une transposition de code C en syntaxe Python, mais une refonte pensée pour être naturelle pour les développeurs Python »

Nouvelles possibilités ouvertes par la prise en charge native de Python

• Jusqu’ici, les utilisateurs de CUDA devaient connaître C++ ou Fortran, mais désormais des calculs GPU haute performance sont possibles avec Python seul
• Selon l’enquête open source GitHub 2024, Python a dépassé JavaScript pour devenir le langage le plus populaire
• Le nombre d’utilisateurs de CUDA est passé de 2 millions en 2020 à 4 millions en 2023, mais les développeurs Python se comptent en dizaines de millions, ce qui représente une très bonne nouvelle, en particulier pour les développeurs des pays émergents comme l’Inde et le Brésil
• On s’attend aussi à un impact positif sur l’extension de l’infrastructure GPU à l’échelle mondiale

Comment est structuré CUDA « Pythonic »

• CUDA se compose de bibliothèques, d’un SDK, de compilateurs, d’un runtime, d’outils et d’algorithmes
• L’intégration de Python ne se limite pas à fournir des kernels ; toute la stack a été pensée pour être compatible avec Python
• Approche clé : compilation JIT (Just-In-Time), afin de minimiser la dépendance aux compilateurs

Principaux composants

• cuPyNumeric : bibliothèque Python offrant la même API que NumPy tout en prenant en charge l’accélération GPU
• CUDA Core : système basé sur un flux d’exécution repensant le runtime CUDA à la manière de Python
• NVMath Python : interface unifiée pour appeler les bibliothèques hôte/périphérique
• Une API Python conçue pour s’interfacer directement avec des bibliothèques C++ haute performance
• Des outils d’analyse des performances et du code sont également fournis

« Il est directement relié au code C++ haute performance existant, donc la perte de performance est presque nulle » — Stephen Jones

Nouveau modèle de programmation : CuTile

• Un modèle de haut niveau centré sur les tableaux conçu pour les développeurs Python
• Là où CUDA exigeait traditionnellement un contrôle détaillé basé sur les threads, CuTile propose une abstraction par tuiles offrant une structure plus concise et plus facile à comprendre
• En mappant les tableaux en tuiles GPU, CuTile facilite le débogage et l’optimisation tout en conservant les performances
• Une extension à CUDA C++ est également prévue par la suite

« Comme le compilateur comprend mieux la structure du GPU, il effectue aussi automatiquement une meilleure optimisation des performances »

En résumé

• L’intégration native de Python dans CUDA abaisse considérablement la barrière d’entrée à la programmation GPU
• Sans connaissances complexes d’autres langages, il devient possible d’effectuer des calculs IA/scientifiques sur GPU avec Python seul
• Il s’agit d’un tournant décisif ouvrant une nouvelle ère pour l’expansion de l’écosystème IA centré sur Python et l’utilisation des GPU NVIDIA

[aer0700]

Est-ce que ce sera finalement plus rapide que les wrappers CUDA existants comme CuPy ou PyTorch ? L’avantage de CuPy et de torch, c’est que leur API est presque identique à celle de NumPy, ce qui permettait de porter sans trop d’effort du code de test écrit avec NumPy ; il faudra voir à l’usage ce qu’il en est pour celui-ci.

[GN⁺]

Avis sur Hacker News

• Je ne suis pas programmeur GPU, mais on dirait que même quelqu’un comme moi pourrait l’utiliser facilement. J’ai fait une petite démo simple utilisant le GPU et le CPU. Les résultats sont les suivants

  • Génération sur CPU de 100 matrices aléatoires de taille 5000x5000
  • Addition de matrices sur CPU
  • Temps d’exécution de l’addition de matrices sur CPU : 0,6541 seconde
  • Taille de la matrice résultat sur CPU : (5000, 5000)
  • Génération sur GPU de 100 matrices aléatoires de taille 5000x5000
  • Addition de matrices sur GPU
  • Temps d’exécution de l’addition de matrices sur GPU : 0,1480 seconde
  • Taille de la matrice résultat sur GPU : (5000, 5000)
  • L’API est vraiment simple, donc ça vaut la peine d’approfondir. Programmer en CUDA ressemble à un gros chantier sans ce type d’abstraction de haut niveau

• Je me demande pourquoi Python devient la cible de ce genre de choses. J’ai vu beaucoup de projets ajouter un support Python. Je me demande s’il est plus facile de compiler une base de code Python vers différentes cibles que d’autres langages

• Heureusement que Pytorch a pris beaucoup d’élan avant que cela n’arrive. Nous avons désormais un vrai quasi-standard réellement indépendant de la plateforme pour le calcul parallèle. Ce n’est pas limité à NVIDIA

  • La partie de Pytorch liée au backend NVIDIA pourrait désormais être implémentée directement en Python
  • Le point important, c’est que cela n’a pas d’importance, ou ne devrait pas en avoir, pour l’utilisateur final / le développeur
  • Cette nouvelle plateforme pourrait peut-être étendre tout le concept du calcul GPU, via Python, à davantage de domaines comme le jeu vidéo
  • Imaginez exécuter des jeux Rust principalement sur GPU via Python

• CuTile donne à bien des égards l’impression d’être le successeur de Triton d’OpenAI. On obtient non seulement des primitives au niveau tile/bloc et TileIR, mais aussi un modèle de programmation SIMT correct dans CuPy. On dirait que peu de gens y ont vraiment prêté attention cette année à la GTC. C’est vraiment très cool

  • Malgré cela, il n’y a eu presque aucune annonce ni présentation liée au CPU. Le CPU Grace a été annoncé il y a déjà un bon moment, mais il ne semble pas qu’on verra bientôt une abstraction généralisée fonctionnant de façon fluide sur les CPU et GPU Nvidia
  • Pour quelqu’un qui travaille tous les jours sur des algorithmes parallèles, c’est un problème. Déboguer avec NSight et CUDA-GDB reste loin d’être équivalent à du GDB brut, et il est bien plus simple de concevoir d’abord l’algorithme sur CPU puis de le porter sur GPU
  • Parmi toutes les équipes qui travaillent sur les compilateurs, Modular est l’une des rares à ne pas s’être complètement laissée happer par la vague LLM et à construire activement des abstractions et des langages couvrant plusieurs plateformes. Cela a de plus en plus de valeur dans cet environnement. J’aimerais voir davantage de gens expérimenter avec Mojo. C’est peut-être cela qui pourra enfin combler le fossé CPU-GPU auquel nous sommes confrontés au quotidien

• Je suis très curieux de voir comment cela se compare à JAX

  • JAX permet d’écrire du code Python qui s’exécute sur des GPU d’autres marques, pas seulement Nvidia (avec un niveau de support variable). Il propose aussi des remplaçants quasi transparents des fonctions NumPy
  • Ici, seul Nvidia est pris en charge. Mais est-ce que cela permet de faire des choses que JAX ne peut pas faire ? Est-ce plus facile à utiliser ? Moins orienté tableaux de taille fixe ? Est-ce que cela vaut le coup de se verrouiller sur une seule marque de GPU ?

• C’est énorme. Plus personne ne considérera probablement AMD + ROCm comme alternative à NVIDIA dans l’IA après ça

  • Je fais partie de ceux qui n’ont pas réussi à apprendre assez de C++ pour écrire efficacement du code destiné à s’exécuter sur GPU, et qui ne l’apprendront probablement pas. Mais là, on peut avoir un pipeline direct vers le GPU via Python. Impressionnant
  • Les implications en matière d’efficacité sont énormes. Pas seulement pour les bibliothèques Python comme PyTorch, mais pour tout ce qui tourne sur des GPU NVIDIA
  • J’aime voir l’efficacité s’améliorer. On entend constamment parler du nombre de centrales nucléaires qu’OpenAI et Google auraient besoin de faire tourner pour alimenter tous les GPU

• Le support de Rust est la prochaine étape ? En ce moment, je [dé]sérialise manuellement mes structures de données en tableaux d’octets vers/depuis les kernels. Ce serait bien d’avoir des structures de données réellement partagées, comme ce que CUDA offre en C++

• Python est vraiment en train de s’imposer comme la lingua franca des langages de programmation. Son adoption explose dans la renaissance du FOSS, et je pense que c’est l’outil le plus proche du couteau suisse universel que nous ayons

  • Le modèle PEP est un bon moyen d’amélioration continue et de standardisation. Grâce à des projets comme uv et BeeWare, le packaging et le déploiement seront bientôt des problèmes résolus. Je suis convaincu que les gains de performance continueront chaque année

• Cela va probablement pousser encore plus ce que Python a généralement toujours favorisé : essayer davantage de choses plus vite, puis laisser ce qui doit rester dans des langages plus rapides y rester. Dans l’ensemble, c’est une excellente décision. J’ai clairement hâte de jouer avec

• CUDA est né avec C et C++. J’aurais préféré qu’ils implémentent une vraie variante C de CUDA au lieu de simplement étendre le C++ et d’appeler cela CUDA C

[iwi19]

La première vitesse, c’est réel ? C’est beaucoup trop lent...