Live data from Hacker News

CUDA-oxide: Nvidia's official Rust to CUDA compiler

nvlabs.github.io

71–80 of 132 posts

Re: CUDA-oxide: Nvidia's official Rust to CUDA compiler

#74

Earlier quoted context omitted.

In AI-focused fields like business analytics and data science, yeah.

The claim is that people are running CUDA on Windows for business analytics and data science? This feels less likely an accurate picture and more likely any mass data processing is already happening on Linux K8s clusters.

Yes, if they happen to run tooling like Excel, PowerBI, Tableau,....

Also Linux support for CUDA on laptops, especially with dual GPU setup isn't particularly great.

Most workstation class laptops are Windows based.

Re: CUDA-oxide: Nvidia's official Rust to CUDA compiler

#75

I wonder what it means for Slang[0]. Presumably the point is that people want to do GPU programming with a more modern language. But now you can just use Rust... (Disclaimer: I like Slang a lot.) [0]: https://shader-slang.org/

They serve different public, Slag folks are more interested in graphics programming not AI algorithms.

Also shading languages are more user friendly given their features.

Finally NVida already has Slang in production and those folks aren't going to rewrite shader pipelines into Rust.

Re: CUDA-oxide: Nvidia's official Rust to CUDA compiler

#76

> (em dash) no DSLs, no foreign language bindings, just Rust. Official CUDA port and they couldn't even bother with the introductory paragraph. Okay, I'll try to ignore it and read the docs. Hey a custom IR, this sounds interesti- > MLIR’s implementation, however, is C++ with a side of TableGen, a build system that requires you to compile all of LLVM, and debugging sessions that make you question your career choices.…

What exactly are you upset about? Someone observing that MLIR is extremely complex and dependent on LLVM...?

Re: CUDA-oxide: Nvidia's official Rust to CUDA compiler

#78
post #58
post #3

This is a bit good for Rust if you want to use the language with CUDA. The problem is, it still doesn't really move the needle if you really don't like running closed source drivers and runtime binaries and care about open source. Continuing from this discussion [0], this only makes it a Rust or a CUDA problem rather than a Python, CUDA and a PyTorch one if there bug in one of them. Yet at the end of the day, it stil…

My sentiment matches your exactly. I'm sick and tired of CUDA - but it's really not going to change. Could maybe be forked with some dynamic smarts, HIP is basically 1:1 with CUDA: https://github.com/amd/amd-lab-notes/blob/release/hipify%2Fs...

Does it support a graphical GPU debugging for C++, Fortran and Python JIT GPU code?

Otherwise it isn't 1:1 with CUDA, and I am not counting everything else on CUDA ecosystem

Re: CUDA-oxide: Nvidia's official Rust to CUDA compiler

#79
post #6

Earlier quoted context omitted.

Mojo remains to be seen if it isn't another Swift for Tensorflow, apparently 1.0 won't even support Windows properly.

[flagged]

All the game devs that forced Valve to come up Proton for Steam Deck to have any content.

Re: CUDA-oxide: Nvidia's official Rust to CUDA compiler

#80

> (em dash) no DSLs, no foreign language bindings, just Rust. Official CUDA port and they couldn't even bother with the introductory paragraph. Okay, I'll try to ignore it and read the docs. Hey a custom IR, this sounds interesti- > MLIR’s implementation, however, is C++ with a side of TableGen, a build system that requires you to compile all of LLVM, and debugging sessions that make you question your career choices.…

What exactly are you upset about? Someone observing that MLIR is extremely complex and dependent on LLVM...?

The quoted writing is AI slop, and OP is reacting to the fact that they did not write even the introductory text themselves (or at least bother to edit out clear AI/slop indicators)
Post reply on HN