Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Nvidia announces native GPU programming in Rust

developer.nvidia.com

Post reply on HN
Print view View original

371–380 of 383 posts

Re: Nvidia announces native GPU programming in Rust

#371

Post by jjtheblunt »

tombert wrote: post #45
jacobgorm wrote: post #12

I strongly dislike CUDA. Once you have allowed that proprietary cr*p into your C++ codebase, it is very hard to get rid, and you end up with code that is either tied to a single vendor or an #ifdef hell, probably both. The best way to program GPUs is face up to the reality that they are not the same machine as the CPU, write your kernels in separate files, and launch them manually, like in Metal, OpenCL, and D3D12, e…

> I strongly dislike CUDA. Once you have allowed that proprietary cr*p Genuine question...why not just type "crap"? It's not even that much of a curse, but I've never really understood the point of self-censorship. If you don't want to curse then you could just use a non-curse word.

he could be a farmer and didn't want to type crop.

alternately, perhaps he meant to match all of cp, crp, crrp, crrrp, and so on. the dude might really like regexes.

/s

Re: Nvidia announces native GPU programming in Rust

#372

Post by MisterTea »

fg137 wrote: post #28
jacobgorm wrote: post #12

I strongly dislike CUDA. Once you have allowed that proprietary cr*p into your C++ codebase, it is very hard to get rid, and you end up with code that is either tied to a single vendor or an #ifdef hell, probably both. The best way to program GPUs is face up to the reality that they are not the same machine as the CPU, write your kernels in separate files, and launch them manually, like in Metal, OpenCL, and D3D12, e…

> Once you have allowed that proprietary cr*p into your C++ codebase People have been doing that all the time for every kind of codebase. It's just part of the business. I don't see how it's worth having any emotions or opinions about it. Seems like you are wasting your energy. Are win32 APIs proprietary? So you decide to use them, use a wrapper/UI framework, or don't develop for Windows. Easy choice. Developing for…

> I don't see how it's worth having any emotions or opinions about it. Seems like you are wasting your energy.

Some people only care about the easiest path to their pay check. Some people actually care about software engineering. I tend to prefer the latter but hamstrung by the former.

Re: Nvidia announces native GPU programming in Rust

#373

Post by corysama »

VikingCoder wrote: post #367
floil wrote: post #359

Earlier quoted context omitted.

They don't release it because exposing a stable instruction set would kill their ability to quickly iterate, to release silicon with bugs that can be papered over with software fixes, as fixing bugs in chips is very expensive in terms of time to market, and undoubtedly to charge more for what looks like a hardware feature but actually is a software feature. It's been this way for 25 years and I don't see it changing.

A stable instruction set would be nice. But hi, if I spent $10,000 on a piece of hardware, let me program the metal, thanks.

I've been programming GPUs since the PlayStation1. The way they work under the hood has changed fundamentally maybe 4 times in that span.

I can't compare it to changes I've seen in CPU architecture since then. Maybe like: Compare the NES with its 6502 and per-cartridge mappers vs. a IBM 386 PC. Now repeat that shift 2 or 3 more times.

Re: Nvidia announces native GPU programming in Rust

#374

Post by suresk »

tete wrote: post #361
suresk wrote: post #245

Earlier quoted context omitted.

> Please don't. I will. Can these be wrong? Certainly. So can humans. Many of your examples are of humans being wrong. That doesn't make LLMs - or humans - useless. The fact that they are not infallible is not a reason to avoid using them and I'm not going to throw out a tool that has been incredibly valuable to me because someone on the internet got some bad CORS advice.

There is another option. Going to the source of information (eg. the official project site or code), trying stuff yourself.

Learning is about so much more than accessing information, though. It is about building mental models, resolving ambiguity, exploring things that the source doesn't explain very well, and so much more.

Questions like "What do these lines of code do?" or "How does this fit into the big picture?" or "Wait, this doesn't make sense?" are rarely answered by the source.

This is a bit fresher in my mind in the math domain, but I don't think it is any different in any number of other domains, including coding. I've been working through a math textbook, gotten confused about how the author gets from step 2 to step 3, taken a picture of the text, and had AI explain it to me - it almost always gives me a much better understanding of what is going on and helps make things so much clearer. There is a level of interactivity that can't exist in a book or other "source" of information.

I think there is a bit of tension when it comes to learning and sometimes the struggle itself is informative, but there is a reason people hire tutors and go to classes taught by teachers vs just reading a textbook, and cutting yourself off from a tool because you've seen it be wrong about something seems like a silly mistake.

Re: Nvidia announces native GPU programming in Rust

#375

Post by ActorNightly »

high_na_euv wrote: post #299
oblio wrote: post #248

Earlier quoted context omitted.

I meant LLMs :-)

You are trying to say that llm can replace compiler?

Why is this even a question, of course they can.

Write python code, ask any llm to translate it to C, then compile the C code - if it produces errors or fails to run, ask LLM to fix it. Then take it a step further and ask it produce machine code, and repeat the procedure.

Then RL the llm on the above, and you basically have a Python -> Machine code compiler. If you cover every single possible python syntax, every single possible C syntax, every possible standard library call, and all the compiler optimization examples (all of which is a final set), you should get something that is extremely accurate.

Re: Nvidia announces native GPU programming in Rust

#376

Post by ActorNightly »

jacobgorm wrote: post #12

I strongly dislike CUDA. Once you have allowed that proprietary cr*p into your C++ codebase, it is very hard to get rid, and you end up with code that is either tied to a single vendor or an #ifdef hell, probably both. The best way to program GPUs is face up to the reality that they are not the same machine as the CPU, write your kernels in separate files, and launch them manually, like in Metal, OpenCL, and D3D12, e…

Yep.

Ive essentially followed that paradigm with Python and C. I start out writing Python code. If I need something to run fast, I build a standalone C application that either reads from a file or listens on a socket, and just invoke it from Python. No need to write the entire thing in Rust and deal with all its semantics when it will be at best like 2% faster.

Re: Nvidia announces native GPU programming in Rust

#377

Post by thaumasiotes »

thaumasiotes wrote: post #323
MisterMunchkin wrote: post #279

Earlier quoted context omitted.

I don't think those filters are even real, I think it's just mass-hysteria. I call these kinds of behaviours "traditions", but I'm not sure if there's a better term for it. Basically someone comes up with something which is nonsensical, but plausible. Like believing that their videos are unpopular because they said the word "rape" and the algorithm magically got them, rather than because their videos suck. Then someo…

> I call these kinds of behaviours "traditions", but I'm not sure if there's a better term for it. In psychology that kind of thing is referred to as "superstition". More specifically, "superstition" in this sense refers to the phenomenon of copying someone else's successful approach to a problem you have. (In your example, getting views on youtube.) Since you don't know what parts of their approach matter, you copy…

Actually, I was a little too specific here - superstition also refers to copying your own successful approach.

Re: Nvidia announces native GPU programming in Rust

#378

Post by LtdJorge »

laggui wrote: post #355
the__alchemist wrote: post #333

Earlier quoted context omitted.

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; n…

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. (disclosure: I am a contributor)

It's very cool. If Rust had comptime, apart from macros, it would be unmatched in capabilities.

Re: Nvidia announces native GPU programming in Rust

#379

Post by HexDecOctBin »

chkmr wrote: post #228
HexDecOctBin wrote: post #190

Anyone know when Rust's std::autodiff will become stable? Assuming this Rust support expands to other GPU vendors, autograd will probably be the only reason to use Slang instead of Rust anymore.

I was told in the 2025 LLVM dev meeting that it will always stay in nightly because it's not practical for them to provide long-term stability guarantees that is expected of stable Rust.

That's a shame
Post reply on HN