Booth: A CUDA, HIP and Triton compiler that also targets plain x86-64

What Booth actually solves

Most GPU compilers assume you own a GPU. Booth does not. It takes CUDA C, HIP, or Triton source and emits binaries for AMD RDNA 2/3/4, NVIDIA PTX, Tenstorrent Metalium C++, or native RV32IM, and also plain x86-64 that runs on a laptop with no GPU. The README is explicit that this last target still surprises its author. For an engineer, that is the core value: you can write a Triton kernel with a matmul and execute it on a machine that has never seen a GPU, without LLVM and without installing a GPU driver. The intended user is someone who wants to develop or test GPU-style kernels in a CPU-only environment, or who needs to target multiple GPU vendors from one source tree. The project also accepts Fortran `do concurrent` kernels via LFortran, and OCaml kernels type-checked by `ocamlc`, which broadens the audience beyond CUDA and Triton users.

How the compiler is structured

Booth is a single C program, built with a C99 compiler and nothing else. The binary is called `kath`, not `booth`, because a Linux HA stack already owns the name `booth`. The compiler reads CUDA, HIP, or Triton source directly. For Fortran, it relies on LFortran to emit CUDA source, which Booth then compiles the rest of the way. For OCaml, it reads the `.cmt` file that `ocamlc` produces after type-checking. The README describes a data flow where two frontends depend on external compilers but the core build does not. The compiler performs SSA register allocation, divergence analysis, and dominator computation, with academic credit given to Cooper, Harvey and Kennedy, Braun and Hack, and Sampaio, Souza, Collange and Pereira. The output for AMD is a `.hsaco` binary, for NVIDIA it is PTX, and for CPU it is native machine code. The x86-64 path is notable because it goes straight to native without LLVM, which the README claims is unusual for a Triton compiler.

Getting it running

The quickest path is a prebuilt binary from the releases page, which comes with no dependencies. After extracting the tarball, you run `./kath --version` to confirm it works. The README gives a concrete compile example: `./kath --amdgpu-bin kernel.cu -o kernel.hsaco` compiles a CUDA kernel to an AMD GPU binary. If you want to build from source, `make` is the entire build command, requiring only a C99 compiler. For the Fortran frontend, you need LFortran installed; for the OCaml frontend, you need OCaml 5.x and dune. The docs directory contains a full command reference in `docs/usage.md`, a CMake integration guide in `docs/cmake.md`, and a feature status list in `docs/features.md`. The README also mentions a runtime launcher, though it does not give the exact command, so you would need to read the usage doc for that.

Real limitations and wrong-tool cases

Booth is a hobbyist project, and the README does not hide that. The feature status document exists precisely because not everything compiles yet. If you need the latest CUDA features or a specific PTX instruction that is not implemented, you will hit a wall. The OCaml path requires `ocamlc` to type-check the kernel, which means you must write kernels as OCaml functions, not as CUDA C; that is a different programming model than most GPU developers use. The Fortran path depends on LFortran, which itself is a moving target. The x86-64 backend is impressive but it is not a GPU emulator; it runs the kernel on the CPU, so performance for compute-heavy kernels will not match a real GPU. If your goal is to benchmark actual GPU performance, Booth is the wrong tool. The README also notes that the binary is named `kath`, which can confuse build scripts that expect `booth`.

A real alternative: Triton's own JIT

The most direct alternative is Triton's JIT compiler, which is what Booth aims to replace for CPU execution. Triton's JIT compiles Triton kernels to GPU code at runtime, using LLVM underneath. It does not target x86-64 as a first-class backend; you would typically run Triton on a GPU. Booth's approach differs by compiling ahead of time to native CPU code without LLVM, which means you can run a Triton kernel on a machine with no GPU and no LLVM installed. That is a fundamental difference in toolchain philosophy: Triton is a runtime JIT tied to the GPU, while Booth is a static compiler that can emit CPU binaries. For someone who wants to test Triton kernels in CI on CPU-only runners, Booth offers a path that Triton itself does not. However, Triton has a much larger community and more mature support for the latest GPU features, so for production GPU work, Triton's JIT remains the safer choice.

Operational discipline from the mainframe world

Booth borrows concepts from mainframe computing that are rare in open-source compilers. The README mentions real crash dumps when a kernel faults, structured output routed by class, and parameter snapshots on entry. These are documented in `docs/mainframe.md`. For an engineer, that means when a kernel crashes, you get a diagnostic artifact you can inspect, rather than a cryptic error message. This is a genuine differentiator: most GPU compilers give you a stack trace at best. The README also references ABEND dumps, SNAP, SYSPRINT, and TDF, which are mainframe terms for abnormal termination, memory snapshots, output streams, and trace data. If you have worked with z/OS or similar systems, these will feel familiar. If not, the docs are there to explain them. This operational focus is a point of view that the project clearly cares about, and it is worth reading the mainframe doc before you dismiss the project as a toy.

Maintenance, license, and upgrade cost

The project is licensed under Apache 2.0, which means you can use it commercially without restriction, though the README asks that you contact the author if it ends up in production. There is no mention of a formal maintenance schedule, but the repository shows recent releases in 2026, including v0.5.2, v5.01, and v0.5.0, so the project is actively developed. The version numbering is inconsistent, with v5.01 appearing between v0.5.2 and v0.5.0, which suggests the author does not follow semantic versioning strictly. Upgrade cost depends on which frontend you use: the core compiler has no external dependencies, so upgrading is as simple as replacing the binary. If you use the Fortran or OCaml frontends, you must also keep LFortran or OCaml versions in sync, because Booth reads their output formats. The feature status document is the best place to track what changes between releases, and the CHANGELOG.md file tracks what changed. For a single-maintainer project, the documentation is unusually thorough, but do not expect enterprise-grade support.

Editorial conclusion

Adopt Booth if you need to run Triton or CUDA kernels on machines without a GPU, or if you want a single compiler that emits AMD, NVIDIA and CPU binaries from the same source. Do not adopt it if you require production-grade robustness, a large community, or support for the latest CUDA features; the feature status document is the place to check what actually compiles. Before committing, verify that your specific kernels are supported, test the x86-64 backend on a non-GPU machine, and review the crash dump and structured output behaviour described in the mainframe docs, because those are the parts that differ from a typical hobby compiler.

Official sources

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