Thread

1. dllu · 1789597370 · focus · HN ↗

   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.

   [1] <a href="https:&#x2F;&#x2F;github.com&#x2F;huggingface&#x2F;candle" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;huggingface&#x2F;candle

   1. jacobgorm · 1789599363 · focus · HN ↗

      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.

      1. [deleted] · 1789600445 · focus · HN ↗

         [deleted]

      2. cpill · 1789600723 · focus · HN ↗

         oh no no no, this is going to break the CPP hold on AI and game dev.

         1. pjmlp · 1789622911 · focus · HN ↗

            Nah, Rust compiler still needs C++ to be built in first place, and everyone on AI uses LLVM as infrastructure.
      3. keithnz · 1789601228 · focus · HN ↗

         kernels aren&#x27;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.

         1. chadcmulligan · 1789606025 · focus · HN ↗

            And quite a few reasons that something better than C should be used. Rust seems a good candidate.

            1. jacobgorm · 1789671283 · focus · HN ↗

               What reasons would you have to prefer Rust over C for compute kernels? I am a great fan of Rust, but I don&#x27;t see any benefit for kernels, due to their relatively simple nature.

               1. chadcmulligan · 1789706904 · focus · HN ↗

                  I&#x27;m not sure why being relatively simple would mean C over Rust? Rust still has the safety advantages.
      4. pjmlp · 1789622844 · focus · HN ↗

         That is exactly why OpenCL failed adoption, focusing on C, instead of being polyglot like CUDA.

         1. zozbot234 · 1789624400 · focus · HN ↗

            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.)

            1. pjmlp · 1789624882 · focus · HN ↗

               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&#x27;t cared one second about it.

               You may mention Codeplay, which is anyway an Intel owned company since 2022.

               As for Vulkan, it doesn&#x27;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.

      5. Anoian · 1789631811 · focus · HN ↗

         I have never seen a comment this gray

         1. jacobgorm · 1789639517 · focus · HN ↗

            I haven&#x27;t felt this popular since then 1990s when I was opposing Visual J++ and IIS.
         2. derpyzza · 1789641152 · focus · HN ↗

            in all of hackernews&#x27; shitty UX decisions, gray unreadable comments is one of the worst ones

Unofficial Hacker News client; not affiliated with Y Combinator.