Booth: Ein CUDA-Compiler, der ohne LLVM auskommt und auf der CPU läuft

Ein Compiler, der die GPU-Werkzeugkette auf den Kopf stellt

Booth löst ein Problem, das viele GPU-Entwickler kennen: Man schreibt Kernel in CUDA oder HIP und ist dann an die Compiler von NVIDIA oder AMD gebunden. Booth will diese Abhängigkeit aufbrechen, indem es CUDA C, HIP und Triton in Binaries für AMD RDNA 2/3/4, NVIDIA PTX, Tenstorrent Metalium C++ oder sogar native RV32IM übersetzt. Besonders ungewöhnlich ist der x86-64-Pfad: Ein Triton-Kernel, inklusive Matmul, lässt sich auf einem Laptop ohne GPU ausführen, und das ohne LLVM. Der README betont, dass Booth direkt Maschinencode erzeugt, nicht über eine Zwischenrepräsentation wie LLVM IR. Das ist ein architektonischer Bruch mit dem, was nvcc oder ROCm üblich machen. Die Zielgruppe sind vermutlich Hobbyisten, Forscher und alle, die eine schlanke Toolchain schätzen, aber auch Unternehmen, die GPU-Code ohne die großen Vendor-Stacks ausliefern wollen.

So arbeitet Booth: Frontends, SSA und ein Hauch Mainframe

Der Datenfluss ist im README grob skizziert: Booth nimmt Quellcode von CUDA, HIP oder Triton entgegen und erzeugt daraus direkt Zielcode. Für Fortran und OCaml gibt es eigene Frontends, die auf andere Compiler setzen. LFortran übersetzt Fortran-do-concurrent-Kernel in CUDA-Quellcode, den Booth dann weiterverarbeitet. OCaml-Kernel werden von ocamlc typgeprüft, und Booth liest die .cmt-Datei. Das ist ein interessanter Ansatz, weil die Typprüfung vor Booth passiert, also bevor der eigentliche Compiler läuft. Der README erwähnt eine SSA-Registerallokation, die auf Gesprächen mit Fernando Magno Quintão Pereira basiert, und Divergenzanalyse nach Papers von Sampaio, Souza, Collange und Pereira. Dazu kommen betriebliche Eigenheiten aus der Mainframe-Welt: echte Crash-Dumps bei Kernel-Fehlern, strukturierte Ausgabe nach Klassen und Parameter-Snapshots beim Eintritt. Das klingt nach einem Compiler, der auf Robustheit ausgelegt ist, nicht nur auf Geschwindigkeit. Die Details stehen in docs/mainframe.md, aber schon die Erwähnung zeigt, dass Booth mehr will als ein weiterer Spielzeug-Compiler.

Installation und erste Schritte: kath statt booth

Der Einstieg ist bewusst einfach gehalten. Auf der Release-Seite gibt es vorgebaute Pakete für Linux, macOS und Windows, die keine Abhängigkeiten mitbringen. Nach dem Entpacken reicht ein Aufruf von ./kath --version. Der Binary heißt kath, nicht booth, weil es im Linux-HA-Stack bereits ein Programm namens booth gibt. Das ist eine wichtige Falle, die der README explizit anspricht, denn auf einem typischen Linux-System könnte es zu Verwechslungen kommen. Wer selbst bauen will, braucht nur einen C99-Compiler und make. Kein CMake, keine externen Bibliotheken. Die Frontends für Fortran und OCaml sind optional, aber man benötigt LFortran beziehungsweise OCaml 5.x und dune, wenn man diese Sprachen nutzen will. Ein Beispiel aus dem README zeigt, wie man eine CUDA-Kernel-Datei in ein AMD-Binary übersetzt: ./kath --amdgpu-bin kernel.cu -o kernel.hsaco. Das ist direkt und ohne Umwege, was zu dem minimalistischen Ansatz passt.

Grenzen und Stolpersteine: Nicht alles kompiliert heute

Der README verweist auf docs/features.md, in der steht, was heute kompiliert und was nicht. Das ist ein ehrlicher Hinweis darauf, dass Booth noch nicht den vollen Funktionsumfang von CUDA oder HIP abdeckt. Wer also bestehende, komplexe Kernel portieren will, muss mit Einschränkungen rechnen. Ein weiterer Stolperstein ist die Abhängigkeit von LFortran und OCaml für bestimmte Frontends. Diese sind nicht in Booth integriert, sondern werden extern benötigt. Das bedeutet, dass man für Fortran-Kernel eine zweite Toolchain installieren muss, was den schlanken Ansatz etwas relativiert. Außerdem ist die Zielhardware begrenzt: AMD RDNA 2/3/4, NVIDIA über PTX, Tenstorrent und RV32IM. Ältere AMD-Architekturen oder Intel-GPUs werden nicht erwähnt. Wer also auf einer nicht unterstützten GPU arbeitet, kann Booth nicht nutzen. Die x86-64-Ausgabe ist nett, aber sie ist kein Ersatz für echte GPU-Beschleunigung, sondern eher ein Debugging- oder Testwerkzeug.

Alternativen: LLVM-basierte Compiler und die Frage nach der Reife

Die naheliegende Alternative zu Booth sind die etablierten Compiler wie nvcc von NVIDIA, ROCm/HIP von AMD und Triton selbst, das normalerweise auf LLVM aufbaut. Der entscheidende Unterschied liegt in der Architektur: Diese Compiler nutzen LLVM als gemeinsame Basis, um Optimierungen und Codegenerierung zu vereinheitlichen. Booth verzichtet bewusst auf LLVM und erzeugt direkt Maschinencode. Das hat Vorteile: weniger Abhängigkeiten, schnellere Builds, und man kann auf einem Rechner ohne GPU arbeiten. Der Nachteil ist, dass man auf die Implementierung von Booth angewiesen ist, wenn es um neue Architekturen oder Optimierungen geht. LLVM profitiert von einer riesigen Community und jahrzehntelanger Entwicklung, Booth ist laut README das Projekt eines Hobbyisten, der sich auf akademische Arbeiten stützt. Das ist nicht negativ gemeint, aber es bedeutet, dass die Feature-Abdeckung und die Stabilität nicht mit den großen Toolchains mithalten können. Für jemanden, der nur gelegentlich Kernel schreibt, mag Booth ausreichen, für ernsthafte Produktentwicklung ist es ein Risiko.

Wartung und Lizenz: Apache-2.0 und ein offenes Ohr

Booth ist unter Apache-2.0 lizenziert, was bedeutet, dass man den Code frei nutzen, modifizieren und kommerziell einsetzen kann. Der README sagt sogar: Do whatever you want. Das ist eine sehr permissive Lizenz, die keine Copyleft-Verpflichtungen wie bei GPL mit sich bringt. Allerdings gibt es keine Garantie für langfristige Wartung. Das Projekt wird offenbar von einer Einzelperson gepflegt, Zane Hambley, und die letzten Releases sind regelmäßig, aber das ist kein Versprechen für die Zukunft. Der CHANGELOG.md dokumentiert Änderungen, was für die Nachvollziehbarkeit gut ist. Wer Booth in ein größeres Projekt integriert, sollte sich überlegen, wie er mit einem möglichen Maintainer-Wechsel umgeht. Die Dokumentation ist im Repository verstreut, aber es gibt eine klare Struktur mit docs/usage.md, docs/features.md und docs/hardware.md. Das ist mehr, als man von vielen Hobby-Projekten erwartet. Die Namenskollision mit dem Linux-HA-Tool booth ist ein praktisches Problem, das man bei der Installation beachten muss, aber es ist kein Lizenzproblem.

Fazit: Ein mutiger Compiler mit klaren Grenzen

Booth ist kein Ersatz für nvcc oder ROCm, aber es ist eine faszinierende Alternative für alle, die ohne LLVM auskommen wollen oder müssen. Die Möglichkeit, Triton-Kernel auf einem Laptop ohne GPU laufen zu lassen, ist ein konkretes Alleinstellungsmerkmal, das in der README mit einem gewissen Stolz erwähnt wird. Wer in einer Umgebung arbeitet, in der GPU-Hardware knapp ist, kann damit Kernel entwickeln und testen, bevor sie auf echte GPUs kommen. Die Unterstützung für OCaml und Fortran ist ein Bonus, der zeigt, dass der Autor über den Tellerrand hinausschaut. Aber man sollte die Erwartungen dämpfen: Die Feature-Liste ist nicht vollständig, und die Hardware-Unterstützung ist auf bestimmte Architekturen begrenzt. Bevor man Booth für ein Projekt adoptiert, sollte man die eigenen Kernel gegen die Liste in docs/features.md prüfen und einen Testlauf auf der Zielhardware machen. Der Compiler ist jung, aber die solide Architektur und die klare Dokumentation machen ihn zu einem Kandidaten für Experimente und für den Einsatz in Umgebungen, die keine schweren Toolchains wollen. Wer bereit ist, sich auf die Eigenheiten einzulassen, findet hier ein Werkzeug, das anders denkt als der Mainstream.

Redaktionelles Fazit

Booth ist für Entwickler gedacht, die GPU-Kernel portabel halten wollen, ohne sich auf LLVM oder die großen Toolchains zu verlassen. Wer Triton-Kernel auf einem Rechner ohne GPU testen möchte, findet hier einen ungewöhnlichen, aber praktikablen Weg. Wer auf volle CUDA- oder HIP-Kompatibilität angewiesen ist, sollte die Feature-Liste in docs/features.md prüfen, denn der README macht klar, dass noch nicht alles kompiliert. Vor einem Produktiveinsatz sollte man die unterstützten Hardware-Plattformen in docs/hardware.md abgleichen und die eigenen Kernel gegen die Referenzwerte testen, wie es die CI mit SLATEC für Fortran tut. Der Compiler ist Apache-2.0-lizenziert, aber die Namenskollision mit dem Linux-HA-Tool booth bedeutet, dass man den Binary-Namen kath im Hinterkopf behalten muss.

Offizielle Quellen

1. Official README
2. Project repository
3. Release notes