Live data from Hacker News

Nvidia announces native GPU programming in Rust

developer.nvidia.com

411–418 of 418 posts

Re: Nvidia announces native GPU programming in Rust

#411
post #28

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…

> It's just part of the business. I don't see how it's worth having any emotions or opinions about it.

It's called foresight. The ability to see that vendor lock-in is against our long-term interests.

Your windows comparison is apt - now we have tons of software tied to windows, making it hard to leave that spyware-infested OS.

Re: Nvidia announces native GPU programming in Rust

#412

Earlier quoted context omitted.

Sounds like a generational thing. I grew up texting. But in the 90s any profanity filters could just be turned off in settings.

You had profanity filters for SMS?

No, but I think ICQ and some IRC clients had profanity filters turned on by default. I remember visiting a friend once and realising he hadn't turned the profanity filter off. I teased him about it for weeks.

Re: Nvidia announces native GPU programming in Rust

#413

Earlier quoted context omitted.

Once again... There's literally no point to a low level shader language for heterogenous back ends.

Why? The point of a shader language is to define a function that outputs some graphics. Why should that not be portable between GPUs/CPUs of different vendors?

Because of how different the memory hierarchies and pipelines are and because if you're doing perf work, this is important enough to matter. For cpus and general purpose programs, it's not. For hpc, it is

Re: Nvidia announces native GPU programming in Rust

#414
post #345

Earlier quoted context omitted.

Why? The point of a shader language is to define a function that outputs some graphics. Why should that not be portable between GPUs/CPUs of different vendors?

More generally any GPU computation, not necessarily graphics. The above argument could go that there is no point in high level languages for CPUs either and everyone should just always use assembly, which is obviously false. Same can go for GPUs.

I mean if you're worried about high performance compute on cpus, then the argument also applies. That's why there so much hand written assembler with dynamic dispatch on CPU features...

It's just that gpus have no general purpose usage .. for ai, it's basically all about perf.

Of course some cross platform stuff can be made for modest acceleration, but the state of the art is always going to be out of reach.

Re: Nvidia announces native GPU programming in Rust

#415
post #85

Earlier quoted context omitted.

> even Nvidia Why "even Nvidia"? They are fully behind using AI for basically everything. What's next? "Damn, even McDonald's is putting out unhealthy food"

McDonald's food is not even that unhealthy. I just tried a Burger King burger the other day and it's terrible. I think it's like 2000 calories in a single burger or something.

Big Mac 580 calories, Whopper 680 calories. At least based on the first official numbers in each google search.

They both have a variety of sizes but it's a similar range and they have similar contents.

Re: Nvidia announces native GPU programming in Rust

#416
post #28

Earlier quoted context omitted.

> 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. Ironic, seeing as that is an opinion about it. Also weird telling people in an online discussion forum not to have opinions.

A pedantic dissection of someone saying "why get worked up about it".

Re: Nvidia announces native GPU programming in Rust

#417
post #28

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…

> People have been doing that all the time for every kind of codebase. It's just part of the business.

What is your ecosystem where this is true?

I'm guessing you assume other people also use the same windows or embedded systems you're referring to.

Obviously, you don't need to live this way. You can be free. Breathe.

CUDA will complicate that. I guess. Maybe. depending on your GPU and workload and tolerance for dealing with nvidia software.

Re: Nvidia announces native GPU programming in Rust

#418

Earlier quoted context omitted.

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

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

I'm not sure why being relatively simple would mean C over Rust? Rust still has the safety advantages.
Post reply on HN