NVIDIA fügt CUDA endlich native Python-Unterstützung hinzu

• Zum 2024 GTC wurde dem über Jahre stark auf C/C++ ausgerichteten CUDA-Toolkit von NVIDIA offiziell native Python-Unterstützung hinzugefügt
• Damit lassen sich nun allein mit Python algorithmuszentrierte Hochgeschwindigkeitsberechnungen direkt auf der GPU ausführen
• CUDA-Architekt Stephen Jones erklärte: „Python CUDA ist nicht einfach nur C-Code in Python-Syntax,
  sondern wurde auf eine für Python-Entwickler natürliche Weise neu entworfen.“

Neue Möglichkeiten durch native Python-Unterstützung

• Bisher mussten CUDA-Nutzer C++ oder Fortran beherrschen, jetzt sind leistungsstarke GPU-Berechnungen auch nur mit Python möglich
• Laut der GitHub Open-Source-Umfrage 2024 hat Python JavaScript überholt und ist zur beliebtesten Sprache aufgestiegen
• Die Zahl der CUDA-Nutzer stieg von 2 Millionen im Jahr 2020 auf 4 Millionen im Jahr 2023,
  Python-Entwickler gibt es jedoch in zweistelliger Millionenzahl – besonders für Entwickler in Schwellenländern wie Indien und Brasilien ist das eine große Chance
• Dadurch werden auch positive Effekte auf den globalen Ausbau der GPU-Infrastruktur erwartet

Wie Pythonic CUDA aufgebaut ist

• CUDA besteht aus Bibliotheken, SDK, Compiler, Runtime, Tools und Algorithmen
• Die Python-Integration stellt nicht nur Kernel bereit, sondern macht den gesamten Stack Python-freundlich
• Kernansatz: JIT-(Just-In-Time)-Kompilierung, um die Abhängigkeit von Compilern zu minimieren

Wichtige Bestandteile

• cuPyNumeric: Python-Bibliothek mit derselben API wie NumPy und GPU-Beschleunigung
• CUDA Core: Ein auf Python zugeschnittenes, ablauforientiertes System mit neu gestalteter CUDA-Runtime
• NVMath Python: Bietet eine einheitliche Schnittstelle zum Aufruf von Host-/Device-Bibliotheken
• Python-API mit direkter Anbindung an leistungsstarke C++-Bibliotheken
• Tools für Performance- und Code-Analyse werden ebenfalls bereitgestellt

> „Da es direkt mit bestehendem Hochleistungs-C++-Code verbunden ist, gibt es so gut wie keinen Performance-Verlust.“ — Stephen Jones

Neues Programmiermodell: CuTile

• Hochstufiges, array-zentriertes Modell, das für Python-Entwickler entwickelt wurde
• Während klassisches CUDA detailgenaue Thread-Kontrolle verlangte, bietet CuTile durch Abstraktion auf Tile-Ebene eine kompakte und leichter verständliche Struktur
• Durch das Mapping von Arrays auf GPU-Tiles macht CuTile Debugging und Optimierung einfacher, ohne Einbußen bei der Performance
• Eine spätere Erweiterung auf C++ CUDA ist geplant

> „Da der Compiler die GPU-Struktur besser versteht, kann er auch die Performance-Optimierung automatisch besser durchführen.“

Fazit

• Die native Python-Integration in CUDA ist eine Veränderung, die die Einstiegshürde für GPU-Programmierung deutlich senkt
• Ohne komplexes Sprachwissen sind nun AI- und wissenschaftliche Berechnungen auf der GPU allein mit Python möglich
• Ein entscheidender Wendepunkt, der eine neue Ära für das Python-zentrierte AI-Ökosystem und die Nutzung von NVIDIA-GPUs einläutet

[aer0700]

Ob es wohl schneller ist als bestehende CUDA-Wrapper wie CuPy oder PyTorch? Der Vorteil von CuPy und torch war, dass ihre API fast identisch mit NumPy ist, sodass man Testcode, den man mit NumPy geschrieben hatte, ohne großen Aufwand übertragen konnte. Wie es sich damit verhält, muss ich wohl selbst ausprobieren.

[GN⁺]

Hacker-News-Kommentare

• Ich bin kein GPU-Programmierer, aber es sieht so aus, als könnten sogar Leute wie ich das leicht nutzen. Ich habe eine einfache Demo mit GPU und CPU gebaut. Die Ergebnisse:

  • 100 Zufallsmatrizen der Größe 5000x5000 auf der CPU erzeugt
  • Matrizen auf der CPU addiert
  • Zeit bis zum Abschluss der CPU-Matrixaddition: 0,6541 Sekunden
  • Größe der CPU-Ergebnismatrix: (5000, 5000)
  • 100 Zufallsmatrizen der Größe 5000x5000 auf der GPU erzeugt
  • Matrizen auf der GPU addiert
  • Zeit bis zum Abschluss der GPU-Matrixaddition: 0,1480 Sekunden
  • Größe der GPU-Ergebnismatrix: (5000, 5000)
  • Die API ist wirklich einfach, also lohnt es sich, tiefer einzusteigen. CUDA-Programmierung wirkt ohne so etwas Hochleveliges wie eine ziemlich große Aufgabe

• Ich frage mich, warum Python für so etwas zum Ziel wird. Ich habe viele Projekte gesehen, die Python-Unterstützung hinzufügen. Ich frage mich, ob sich Python-Codebasen leichter für verschiedene Targets kompilieren lassen als andere

• Zum Glück hat Pytorch schon vor dem Erscheinen davon viel Momentum aufgebaut. Jetzt haben wir einen wirklich plattformunabhängigen Quasi-Standard für paralleles Rechnen. Nicht auf NVIDIA beschränkt

  • Die Teile von Pytorch, die mit dem NVIDIA-Backend zu tun haben, könnten jetzt direkt in Python implementiert werden
  • Der wichtige Punkt ist, dass es für Endnutzer/Entwickler nicht wichtig ist oder nicht wichtig sein sollte
  • Vielleicht kann diese neue Plattform über Python das gesamte Konzept von GPU-Computing auf mehr Domänen wie Spiele ausweiten
  • Stell dir vor, Rust-Spiele über Python hauptsächlich auf der GPU laufen zu lassen

• CuTile fühlt sich in vieler Hinsicht wie ein Nachfolger von OpenAIs Triton an. Man bekommt nicht nur Tile-/Block-Level-Primitives und TileIR, sondern auch ein ordentliches SIMT-Programmiermodell in CuPy. Selbst auf der diesjährigen GTC scheint das kaum jemand wahrgenommen zu haben. Sehr cool

  • Trotzdem gab es fast keine Ankündigungen oder Talks rund um die CPU. Die Grace CPU wurde schon vor einiger Zeit angekündigt, aber es sieht nicht so aus, als würden wir bald eine verallgemeinerte Abstraktion sehen, die nahtlos auf Nvidia-CPUs und -GPUs läuft
  • Für Menschen, die täglich an parallelen Algorithmen arbeiten, ist das ein Problem. Mit NSight und CUDA-GDB zu debuggen ist noch immer nicht wie mit rohem GDB, und es ist viel einfacher, Algorithmen zuerst auf der CPU zu entwerfen und dann auf die GPU zu portieren
  • Unter allen Teams im Compiler-Bereich ist Modular eines der wenigen, die nicht völlig vom LLM-Hype vereinnahmt wurden und aktiv plattformübergreifende Abstraktionen und Sprachen bauen. In diesem Umfeld wird das immer wertvoller. Ich wünschte, mehr Leute würden mit Mojo experimentieren. Vielleicht kann es die CPU-GPU-Lücke, mit der wir jeden Tag konfrontiert sind, endlich schließen

• Ich bin sehr gespannt, wie es sich mit JAX vergleicht

  • Mit JAX kann man Python-Code schreiben, der nicht nur auf Nvidia-, sondern auch auf GPUs anderer Marken läuft (mit unterschiedlichem Support). Ebenso gibt es Drop-in-Ersatz für NumPy-Funktionen
  • Das hier unterstützt nur Nvidia. Aber kann es Dinge, die JAX nicht kann? Ist es einfacher zu benutzen? Weniger auf Arrays fester Größe ausgerichtet? Lohnt es sich, sich auf GPUs einer einzigen Marke festzulegen?

• Das ist großartig. Wer im AI-Bereich AMD + ROCm als Alternative zu NVIDIA in Betracht gezogen hat, wird das nun wohl nicht mehr tun

  • Ich bin einer von denen, die nicht genug C++ gelernt haben (und nicht lernen werden), um effektiv Code für GPU-Ausführung zu schreiben. Aber über Python kann ich jetzt eine direkte Pipeline zur GPU haben. Erstaunlich
  • Die Bedeutung für die Effizienz ist enorm. Nicht nur für Python-Bibliotheken wie PyTorch, sondern für alles, was auf NVIDIA-GPUs läuft
  • Ich sehe gern, wenn die Effizienz verbessert wird. Wir hören ständig davon, wie viele Atomkraftwerke OpenAI und Google brauchen würden, um all ihre GPUs zu betreiben

• Ist Rust-Support das Nächste? Derzeit [de]serialisiere ich meine Datenstrukturen manuell als Byte-Arrays in den Kernel und aus dem Kernel heraus. Es wäre schön, wirklich gemeinsam genutzte Datenstrukturen zu haben, wie CUDA sie in C++ bietet

• Python etabliert sich wirklich als Lingua franca der Programmiersprachen. Die Akzeptanz steigt in der FOSS-Renaissance stark an, und ich denke, es ist das Nächste, was wir an einem universellen Werkzeug haben

  • Das PEP-Modell ist ein gutes Mittel für Selbstverbesserung und Standardisierung. Dank Projekten wie uv und BeeWare werden Packaging und Distribution bald gelöste Probleme sein. Ich bin sicher, dass die Performance sich jedes Jahr weiter verbessern wird

• Das wird wahrscheinlich das fördern, was Python im Allgemeinen schon angetrieben hat: dass mehr Dinge schneller ausprobiert werden und in schnelleren Sprachen verbleiben. Insgesamt ist das ein hervorragender Schritt. Ich freue mich definitiv darauf, damit herumzuspielen

• CUDA wurde in C und C++ geboren. Ich wünschte, man hätte wirklich eine C-Variante von CUDA implementiert, statt einfach C++ zu erweitern und es CUDA C zu nennen

[iwi19]

Ist die erste Geschwindigkeitsangabe wirklich korrekt? Es ist viel zu langsam...