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

411–420 of 422 posts

Re: Nvidia announces native GPU programming in Rust

#411

Post by like_any_other »

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…

> 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

Post by josephg »

nairboon wrote: post #243
josephg wrote: post #167

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

Post by anon291 »

hobofan wrote: post #295
anon291 wrote: post #155

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 by anon291 »

shmerl wrote: post #345
hobofan wrote: post #295

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 by Dylan16807 »

dprkh wrote: post #85
keybrd-intrrpt wrote: post #31

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 by unethical_ban »

Hendrikto wrote: post #257
fg137 wrote: 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 by throwaway27448 »

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…

> 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? Embedded or industrial, maybe?

I'm guessing you assume other people also use the same windows or embedded systems you're referring to. That's an insane thought: nobody would use this if they had any chance, and you intentionally chose this misery.

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

Re: Nvidia announces native GPU programming in Rust

#418

Post by chadcmulligan »

jacobgorm wrote: post #390
chadcmulligan wrote: post #78

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.

Re: Nvidia announces native GPU programming in Rust

#419

Post by uncle_kostya »

miki123211 wrote: post #311
rfgplk wrote: post #281

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

The problem is much deeper than that. Most OSes' syscall ABIs are not stable and could change without warning. What is stable is the dynamically-loaded libraries, shipped as part of the system. Linux is the notable exception here; the Linux kernel project doesn't ship a libc, and Linus is very famously opposed to "breaking userspace." There's nothing that can stop you from using syscalls in theory, but if you want yo…

If I recall correctly, the Golang team got bitten by this on MacOS.

They initially implemented the Golang runtime directly on top of MacOS syscalls (not the C runtime library), just like they did on Linux - and then those syscalls changed, breaking Golang.

They had to switch to the official stable API which on MacOS is the C runtime library, not syscalls.

Re: Nvidia announces native GPU programming in Rust

#420

Post by uncle_kostya »

15155 wrote: post #122
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 don't mind CUDA, I do mind that all of the SDKs don't dynamically load the various CUDA shared libraries at runtime.. intertwining itself into your application linking process makes for extreme binary portability inconvenience.

There a flavor of CUDA runtime libraries that binds at runtime, so you can have a single binary that runs with CUDA and without it. I did this at work.

Obviously you need to check if CUDA is available before trying to execute kernels, or it will error out.

Post reply on HN