Viewing profile — melihelibol
melihelibol
HN member- Joined
- Fri, Sep 25, 2015, 4:39 PM UTC
- HN karma
- 54
- Public activity
- 10 items
- HN profile
- View on Hacker News ↗
About melihelibol
- Author of cuTile Rust: Safe, data-race-free GPU kernels in Rust. github.com/nvlabs/cutile-rs | arxiv.org/abs/2606.15991 | RustConf 2026 - scholar.google.com/citations?user=MvYTnPoAAAAJ
Recent public activity
-
comment
Comment #48588877
[dead]
-
comment
Comment #48581155
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). Thou…
-
comment
Comment #48564395
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 …
-
comment
Comment #48564334
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 mode…
-
comment
Comment #48564253
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…
-
comment
Comment #48563247
Yes! That's exactly the spirit. The readable, single-binary, kernels-included codebase is a big part of what makes Grout fun, and the antirez parallel is accurate. There's a parall…
-
comment
Comment #48563091
You got it right: This project exposes our tile programming model, whereas cuda-oxide exposes our lower level CUDA-like programming model. Our tile programming model is higher-leve…
-
comment
Comment #48561455
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 re…
- story
- story