Live data from Hacker News

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

nvlabs.github.io

51–60 of 132 posts

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

#51
post #19

Personally I really don't want new GPU languages that do not have AD as a first class citizen. I mean rust is an improvement over C++ CUDA but still.

There is actually work on adding autodiff to Rust, maybe not really first class citizen, but at least build in: https://doc.rust-lang.org/std/autodiff/index.html (it is still at a pre-RFC stage so it is not something that soon will be added)

That's awesome, I didn't know that!

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

#54

Why do we bother with programming languages today? Why not have the LLMs just write assembly code and skip the human readable part? We are not reviewing it anymore anyway.

I'll bite:

Programming languages are tools for thinking. It's not clear that assembly code has the right abstractions to encourage the kind of thinking that programming large systems requires. After all, human intelligence found assembly insufficient and went on to invent better languages for thinking, why should artificial intelligence, trained on human intelligence, be any different? Maybe AI in the future will have its own languages for thinking, but assembly is likely not that.

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

#55
post #18

Why do we bother with programming languages today? Why not have the LLMs just write assembly code and skip the human readable part? We are not reviewing it anymore anyway.

A lot of really good reasons: 1) Higher level code is easier for LLMs to review and iterate upon. The more the intent is clear from the code, the easier it is for humans and LLMs to work with. 2) LLMs get stuck or fail to solve a problem sometimes. It is preferable to have artifacts that humans can grok without the massive extra effort of parsing out assembly code. 3) Assembly code varies massively across targets. We…

In addition LLMs also make bugs, and debugging assembler is more difficult, wasting more tokens, thus more money.

A very big practical reason is also that assembler code would eat context like no other.

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

#56

Re: Rust (and "safe" programming languages). Does anyone have more details on NVIDIAs use of Spark/Ada? All I can find is what's listed below: https://www.adacore.com/case-studies/nvidia-adoption-of-spar...

They gave a detailed talk last DEF CON: https://www.youtube.com/watch?v=KhWtkZmOPn4

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

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

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

#59

Earlier quoted context omitted.

This isn't a new GPU language; it's a lib which might replace FFI and third party libs.

This is definitely not just a lib. This compiles rust to CUDA. If you call a full on compiler stack a lib, everything may as well be a lib.

Ok. I am calling it a lib because to use, you add it as a dependency in cargo.toml then import it in your rust modules.
Post reply on HN