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

331–340 of 359 posts

Re: Nvidia announces native GPU programming in Rust

#331

Post by ValleZ »

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.

Not all crap is created equal, some needs censoring.

Re: Nvidia announces native GPU programming in Rust

#332

Post by shevy-java »

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.

> I've never really understood the point of self-censorship.

Some platforms disallow certain words. In order to bypass that, some people use the asterisks. That's just as one possible answer to your question; there can be many different reasons for self-censorship, but to me the most logical one is when one tries to work around crappy restrictions, such as on terrible reddit (they killed old.reddit recently; I retired before that due to moderators being insane, but I also said that if old.reddit is gone, I am gone anyway - the requirement to now log in, totally defeats old.reddit com's usecase. Then again reddit went downhill many years before that already, so not a real loss.)

Re: Nvidia announces native GPU programming in Rust

#333

Post by the__alchemist »

dllu wrote: post #5

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] https://github.com/huggingface/candle

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.

Re: Nvidia announces native GPU programming in Rust

#335

Post by allarm »

xbmcuser wrote: post #70
tombert wrote: post #45

Earlier quoted context omitted.

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

* is used to give emphasis and show that they are using the word as curse word rather just calling it bad

But this isn't perceived as emphasis at all. If I wanted to emphasize something, I'd be more likely to use something like *bitch* or something along those lines. Replacing a letter with an asterisk comes across as self-censorship, which is pretty silly - just use a different word if you're that uncomfortable with swearing.

Re: Nvidia announces native GPU programming in Rust

#336

Post by aseipp »

rfgplk wrote: post #282
Asmod4n wrote: post #215

Earlier quoted context omitted.

Win32 is the most stable abi on the Linux desktop.

Dead wrong. Win32 (externally) only seems stable, but internally it changes between Windows releases. Win7 syscalls are completely different from Win11 syscalls, meaning if I want to release a binary _without relying_ on Win32 I need to provide full syscall mappings _for each and every Windows version_. This doesn't happen on Linux.

> only seems stable, but internally it changes

That's literally the definition of it being stable. Programs written against an interface keep working despite the implementation changing. The Linux kernel also constantly changes internally but programs written against syscalls keep working, so it is stable; that fact doesn't stop being a fact just because I dislike perf_event_open(2) or whatever. This is all very basic and easy to understand.

Re: Nvidia announces native GPU programming in Rust

#337

Post by allarm »

ImHereToVote wrote: post #226
tombert wrote: post #45

Earlier quoted context omitted.

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

What if a toddler is browser HN and sees the curse word?

Oh, my, indeed! That's gonna traumatize the poor dude for life.

Re: Nvidia announces native GPU programming in Rust

#338

Post by surajrmal »

loup-vaillant wrote: post #314

Okay, so, GPUs are taking one more step towards being general purpose massively parallel machines. That's cool. What would be even cooler though would be for GPU vendors to start giving us the user manual. An I mean the real user manual, that explains how to use their piece of metal when all you have is that piece of metal . That means a precise description of the wire protocols, the data format of the buffers we sen…

They don't need to do that to sell their hardware so why would they do that? On the other hand, they have strong incentives to not give you that level of access and information. The only way this will change is by having some disruption by way of a competitor who sells hardware with that feature as being a major reason why it takes off.

Re: Nvidia announces native GPU programming in Rust

#339

Post by pid0x17 »

jacobgorm wrote: post #326
pid0x17 wrote: post #322

Earlier quoted context omitted.

As someone only recently getting into HPC, what do you mean when you say learning things the hard way? What would you suggest? I recently started learning CUDA and parallel programming paradigms.

For learning that may be a fine approach, but CUDA (in C++) really tries to hide what is going on behind the scenes, which is roughly: 1) code gets split between a host part that goes through your normal compiler, and a device part that goes through the GPU compiler. You may as well write the kernels separate and compile them via a separate compilation step, and keep your trusted host compiler for the host-side code.…

Thank you very much for the effort you put into your advice!! I think I will start with WebGPU (wgpu), even though I have an Apple Silicon Macbook. I would really prefer to work with Rust instead of C++ because I am not good with C++. (I believe) I am good with C, so my C++ code looks like C code, and I am kinda learning the differences as I learn CUDA, which is a terrible way to learn C++, I guess.

Re: Nvidia announces native GPU programming in Rust

#340

Post by josephg »

rfgplk wrote: post #281
josephg wrote: post #132

Earlier quoted context omitted.

If you're going to make apps in windows, you need to call their proprietary API somehow. Maybe you do it via a wrapper library, or via electron or something. But that's the same thing, just with more indirection.

> If you're going to make apps in windows, you need to call their proprietary API somehow. Maybe you do it via a wrapper library, or via electron or something. But that's the same thing, just with more indirection. Not even close to being true. You can invoke syscalls directly, just needs a bit of reverse engineering. I wrote a bare metal libc library, with (not a whole lot of) effort I'm fully able to interface with…

> Not even close to being true. You can invoke syscalls directly,

The windows syscall API is yet another proprietary windows API. Sure - you can call it without loading any DLLs. But you're still calling into a proprietary windows API.

If you really hate calling proprietary windows APIs that much, maybe stop developing for windows? Develop software for linux. Or make your own kernel, or whatever. But if you keep developing software for windows, stop fighting it. Unless you have a very good reason, your software should try to fit in on its host platform. It should behave well, and work like other windows software.

It's like travel. If you fly to France, try to fit in. Maybe learn a bit of French before you go. If you hate France, don't go.

Post reply on HN