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.
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.
jacobgorm · · focus · HN ↗
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.
15155 · · focus · HN ↗
uncle_kostya · · focus · HN ↗
Obviously you need to check if CUDA is available before trying to execute kernels, or it will error out.
15155 · · focus · HN ↗