logoalt Hacker News

jacobgormyesterday at 10:54 PM11 repliesview on HN

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, etc. These days we even have DSLs like Triton that make kernel writing much more ergonomic than anything you would hope to achieve in Rust.


Replies

tombertyesterday at 11:44 PM

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

show 3 replies
nicwilsontoday at 12:40 AM

Launching kernels manually is an error prone PITA which I believe is the principle reason for CUDA's popularity. Having the compiler give an error when you mess up is a huge benefit. But having the compiler allow you to express "I want to launch this kernel over a grid with these dimensions, with these arguments" as a single expression is where the vast majority of the value comes from.

The having it all in a single file is mostly an artefact of the fact that it is C++, because C++ is single file at a time compilation. In D (which is multiple files in a single compiler invocation) with DCompute (which targets CUDA and OpenCL with upcoming support for Vulkan and Metal), you are required to write the kernels in a separate module, but you get all the benefits of the compiler complaining when you mess up _and_ the expressivity of "launch me this kernel".

fg137yesterday at 11:16 PM

> 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 embedded devices? So you read the manufacturers manual and implement based on the spec, use some sort of HAL if they are available, or you don't have a job. Even simpler.

show 2 replies
winwangtoday at 1:44 AM

Having also played with Metal and WebGPU (at least years ago), I would say that CUDA is, amazingly, the best GPGPU API we have. Do I wish we had an open source parallel programming language as good or better than it? Yes. But asymmetrically hating on CUDA like this is how we continue to lag behind it in UX.

> 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

Not to mention that this is a completely sane way to use CUDA as well.

15155today at 1:58 AM

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.

throwaway334212today at 2:44 AM

Anyone here looking at Modular's offerings?

pavonyesterday at 11:02 PM

> 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

Isn't that how CUDA code is normally written?

show 1 reply
melodyogonnayesterday at 11:04 PM

You could also use Mojo, one language for all targets.

show 2 replies
anon291today at 2:19 AM

? I find it hard to see the issue here. Just put it in a separate file and call it?

bigyabaiyesterday at 11:00 PM

Is this satire? D3D12 and Metal aren't any less proprietary than CUDA.

show 1 reply
cpillyesterday at 11:22 PM

yeah, just write a stub/wrapper around it and abstract. it's the classic coupling problem. nothing to do with CUDA