Eventual goal is to make this pip installable so it can be interactable within python. This may be particularly useful to people especially as Booth comes with a CPU backend supporting x86 and RISC-V architectures alongside existing GPU support.
Currently Booth is a CLI today which is fine. However, a sizeable portion of people who write kernels usually live in the world of Pytorch and within Python. The end goal is to make it interactable for those users.
Not a goal:
- Not a Triton backend. It's MLIR based and contains LLVM.
- Not a CUDA runtime reimplementation.
- There will be no initial performance claims. I need to actually get this running correctly first.
It will be shipped into a few distinct phases/groups
1: Wheels
setup.py shim over the existing Makefile
- cibuildwheel, which shouldn't be an issue because this has no dependencies.
console_scripts entrypoint. Wheels on releases with checksums
2: In process compilation
libbooth.so plus a ctypes wrapper. There'll be no CPython headers. One wheel per platform across all Python versions
-booth_ctx_create() / booth_ctx_destroy() - no global state; callers compile in parallel. -Caller-frees results -Bringing over Booths structured diagnostics across the ABI -booth.compile (src, target=.....) -booth.targets()` which shows what we currently support.
3 Execution
- Launch a compiled kernel with a grid and arguments
- Buffer transfer in and out
- Uniformity across targets so the same script runs anywhere
If anyones reading and has any ideas:
Uniform launch is hard because different stacks have different support.
Package name, booth may be taken. May have to think of an easy-to-understand name.
Thanks for reading!
Eventual goal is to make this pip installable so it can be interactable within python. This may be particularly useful to people especially as Booth comes with a CPU backend supporting x86 and RISC-V architectures alongside existing GPU support.
Currently Booth is a CLI today which is fine. However, a sizeable portion of people who write kernels usually live in the world of Pytorch and within Python. The end goal is to make it interactable for those users.
Not a goal:
It will be shipped into a few distinct phases/groups
1: Wheels
setup.pyshim over the existing Makefileconsole_scriptsentrypoint. Wheels on releases with checksums2: In process compilation
libbooth.soplus a ctypes wrapper. There'll be no CPython headers. One wheel per platform across all Python versions-
booth_ctx_create() / booth_ctx_destroy() - no global state; callers compile in parallel. -Caller-frees results -Bringing over Booths structured diagnostics across the ABI -booth.compile(src, target=.....) -booth.targets()` which shows what we currently support.3 Execution
If anyones reading and has any ideas:
Uniform launch is hard because different stacks have different support.
Package name, booth may be taken. May have to think of an easy-to-understand name.
Thanks for reading!