Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: cuTile Rust: Safe, data-race-free GPU kernels in Rust

github.com

Post reply on HN
Print view View original

11–20 of 21 posts

Re: Show HN: cuTile Rust: Safe, data-race-free GPU kernels in Rust

#11

Post by melihelibol »

lmeyerov wrote: post #8
melihelibol wrote: post #2

Hello, I built cuTile Rust and just posted the paper preprint. Happy to answer questions. TL;DR: Rust gives you fearless concurrency on the CPU, but GPU kernel programming still requires unsafe code. cuTile Rust carries Rust's ownership model across the launch boundary and maintains it via a safe tile-based programming model that compiles to Tile IR. The host-side GPU work you write composes into synchronous launches…

Any thoughts on layering on-GPU work stealing or cudf on top? For gfql (graph query language mapping down to cudf calls), we're trying to jettison the hot loop of python->cpu->gpu, so been loosely watching cuTile evolve!

I think the answer's actually yes. I'll give the short rationale here, but it's a deep topic and I'd be happy to take it further.

The hot loop you're describing is the whole reason you'd want to reach for a systems language over Python: once the orchestration lives in the interpreter, you pay for the round-trip every iteration. There are now two tile-based ways to do that in a compiled language: CUDA C++ Tile and cuTile Rust. Both get you out of Python and into the same tile model. What cuTile Rust adds is the safety layer: Rust's ownership model gives you compile-time memory safety and data-race freedom (we prove it in the paper), which the C++ path doesn't. So if you're moving off Python anyway, the real question is whether you want those guarantees.

How much of gfql maps cleanly depends on your specific ops and how the pipeline's structured. Happy to dig into it if you open an issue.

Re: Show HN: cuTile Rust: Safe, data-race-free GPU kernels in Rust

#12

Post by melihelibol »

cogman10 wrote: post #10
melihelibol wrote: post #2

Hello, I built cuTile Rust and just posted the paper preprint. Happy to answer questions. TL;DR: Rust gives you fearless concurrency on the CPU, but GPU kernel programming still requires unsafe code. cuTile Rust carries Rust's ownership model across the launch boundary and maintains it via a safe tile-based programming model that compiles to Tile IR. The host-side GPU work you write composes into synchronous launches…

Has there been any thought/exploration in non-nvidia platforms? ROCm, vulkan, metal, npus, opencl, etc?

cuTile Rust lowers through CUDA Tile IR, which is NVIDIA-specific, so any of those targets (ROCm, Vulkan, Metal, NPUs, OpenCL) would be a new compiler backend. The programming model itself isn't NVIDIA-bound, but the lowering is.

Re: Show HN: cuTile Rust: Safe, data-race-free GPU kernels in Rust

#13

Post by melihelibol »

genxy wrote: post #9

See also https://github.com/tracel-ai/burn

Burn's great, and we cite it in the paper's related work. Different layer, though: Burn is the high-level DL framework (tensor ops, autodiff, backends), whereas cuTile Rust is the kernel-authoring layer underneath. The closer neighbor is actually CubeCL, Tracel's compute layer that Burn sits on, and there's an open issue to integrate cuTile Rust into CubeCL, so we're already looking at how these fit together. See https://github.com/tracel-ai/cubecl/issues/1282

Re: Show HN: cuTile Rust: Safe, data-race-free GPU kernels in Rust

#16

Post by genxy »

melihelibol wrote: post #13
genxy wrote: post #9

See also https://github.com/tracel-ai/burn

Burn's great, and we cite it in the paper's related work. Different layer, though: Burn is the high-level DL framework (tensor ops, autodiff, backends), whereas cuTile Rust is the kernel-authoring layer underneath. The closer neighbor is actually CubeCL, Tracel's compute layer that Burn sits on, and there's an open issue to integrate cuTile Rust into CubeCL, so we're already looking at how these fit together. See htt…

Yeah, I linked to Burn since it was the parent framework, but yes CubeCL. Still blows my mind that they basically implemented a subset of Rust inside of a Rust macro so you can write your compute kernels in Rust.

Nathaniel Simard: "Rust for AI & Accelerated Computing" | RustConf 2025 https://www.youtube.com/watch?v=RaSxyRQ7egU

Re: Show HN: cuTile Rust: Safe, data-race-free GPU kernels in Rust

#18

Post by ericlbuehler »

binarybana wrote: post #3

I'm excited to see what cuTile-rs unlocks. Like the direction of HuggingFace's grout https://github.com/huggingface/grout project for local LLM inference: - state of the art performance - codebase that fits in a context window (including kernel definitions!) - single binary deployment Similar to antirez's ds4.c, but in Rust and with cuTile making kernels both easier to author and higher performance.

Hey! Eric here, one of the folks behind Grout (from HF). The small codebase was a deliberate goal, as the whole engine including kernels is meant to be minimal and readable end to end, which is only practical because cuTile lets us write the kernels in Rust instead of a separate CUDA file. I think this makes things super promising for Rust + CUDA development and rapid iteration!

Re: Show HN: cuTile Rust: Safe, data-race-free GPU kernels in Rust

#19

Post by melihelibol »

wizenheimer wrote: post #7

Looks interesting. For someone already comfortable with Triton, what's the strongest argument for choosing cuTile Rust instead? Is the main differentiator the ownership-based safety model, tighter integration with Rust ecosystems, or idk are there workloads where the Tile IR pipeline has advantages beyond language ergonomics?

Yes, the ownership-based safety model and tight Rust integration, plus a pretty fleshed-out host-side tensor API for different workloads (sync, async, replayable CUDA graphs).

Though Triton's a Python DSL, so there's no official Triton Rust to do an apples-to-apples comparison. Being pointer-based, it's unclear how one would reason about memory safety and data-race freedom. As a point-of-comparison, cutile-rs supports both pointers and tensors. We're only able to statically reason about safety when folks operate on tensors directly. The pointer path remains unsafe.

Post reply on HN