Since NVIDIA owns huggingface now and huggingface has the excellent Candle [1] crate for inference on Rust, this seems like a good step towards nice native Rust kernels.
Nobody cares if kernels are written in Rust. Kernels were meant to be written in C, but if you want to go more high-level try Triton or a similar DSL that nicely abstract tile sizes etc.
kernels aren't meant to be written by any defined language. C is just a traditionally good default language that took over from assembly. No particular reason we have to stick with C.
What reasons would you have to prefer Rust over C for compute kernels?
I am a great fan of Rust, but I don't see any benefit for kernels, due to their relatively simple nature.
SYCL is the natively polyglot counterpart, with practical implementations of it compiling down to the same sort of SPIR-V kernels as OpenCL. (OTOH, much of the current adoption on the open standards side seems to target the more widely supported SPIR-V compute shaders, via Vulkan compute.)
Not really, first of all it is for C++, not the range of languages supported by CUDA.
Before SPIR was a thing in OpenCL, Khronos could not understand why anyone would care about anything else other than C99, or why supporting Fortran on GPUs was at all relevant.
Secondly, from the competition only Intel cares about SYCL with their own sugar on top, OpenAPI.
AMD hasn't cared one second about it.
You may mention Codeplay, which is anyway an Intel owned company since 2022.
As for Vulkan, it doesn't have neither the features, nor the tooling that CUDA enjoys, it is the usual putting up with using LEGOs from different brands, with various pin sizes, that is so common with Khronos.
I will give you an outsider's perspective on an analogy in this case. It is easy to see Candle as a ML crate to use for neural networks in rust. I have used it, and it works well.
The analogy is Tensorflow 5-10 years ago. It is popular, and there are lots of material on it. You quickly learn from talking to people that due to whims, a collection of reasons, people's love of consensus that no one is recommending it; new people are not learning it. In this case, the Torch analogy is the Burn lib.
And to tie this back into GPU programming, Burn's backends use CubeCL, which lets you write compute kernels in a Rust DSL using #[cube], with a JIT compiler and autotuning machinery. It targets CUDA, AMD, Metal, Vulkan and WebGPU.
Integration with candle is already available! <a href="https://github.com/huggingface/candle/pull/3934/" rel="nofollow">https://github.com/huggingface/candle/pull/3934/
dllu · · focus · HN ↗
[1] <a href="https://github.com/huggingface/candle" rel="nofollow">https://github.com/huggingface/candle
jacobgorm · · focus · HN ↗
[deleted] · · focus · HN ↗
[deleted]
cpill · · focus · HN ↗
pjmlp · · focus · HN ↗
keithnz · · focus · HN ↗
chadcmulligan · · focus · HN ↗
jacobgorm · · focus · HN ↗
chadcmulligan · · focus · HN ↗
pjmlp · · focus · HN ↗
zozbot234 · · focus · HN ↗
pjmlp · · focus · HN ↗
Before SPIR was a thing in OpenCL, Khronos could not understand why anyone would care about anything else other than C99, or why supporting Fortran on GPUs was at all relevant.
Secondly, from the competition only Intel cares about SYCL with their own sugar on top, OpenAPI.
AMD hasn't cared one second about it.
You may mention Codeplay, which is anyway an Intel owned company since 2022.
As for Vulkan, it doesn't have neither the features, nor the tooling that CUDA enjoys, it is the usual putting up with using LEGOs from different brands, with various pin sizes, that is so common with Khronos.
Anoian · · focus · HN ↗
jacobgorm · · focus · HN ↗
derpyzza · · focus · HN ↗
instagraham · · focus · HN ↗
jvanderbot · · focus · HN ↗
the__alchemist · · focus · HN ↗
The analogy is Tensorflow 5-10 years ago. It is popular, and there are lots of material on it. You quickly learn from talking to people that due to whims, a collection of reasons, people's love of consensus that no one is recommending it; new people are not learning it. In this case, the Torch analogy is the Burn lib.
laggui · · focus · HN ↗
(disclosure: I am a contributor)
LtdJorge · · focus · HN ↗
melihelibol · · focus · HN ↗