Makes me sad that Go doesn't get love. I feel like Go is perfect for LLMs.
Go's type system is not at the same level as C++, Fortran, Python, Julia, Haskell, Java, to quote the languages with CUDA support from NVIDIA and their partners.
Nvidia announces native GPU programming in Rust
191–200 of 321 posts
Re: Nvidia announces native GPU programming in Rust
#192AI slop article, how can I trust on this?
The same way as people trust AI sloppy on their code.
Re: Nvidia announces native GPU programming in Rust
#193I 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.
cause you might go to the eternal flames if you say a no-no word online
Re: Nvidia announces native GPU programming in Rust
#194Earlier quoted context omitted.
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…
> Having the compiler give an error when you mess up is a huge benefit. Shouldn't this be alleviated by the current code generation machines?
Well yeah, but then you are using code generation, not writing code directly.
Re: Nvidia announces native GPU programming in Rust
#195Earlier quoted context omitted.
The CPU on most machines is quite proprietary. I don’t understand this faux purity dogma. Practical computing is not and never has been an abstract pure concept. It’s about making machines built by corporations to do usefull things at scale. There is no ”non proprietary” computing unless you make your own stack.
Yes but there are business costs to using high-level proprietary tools and libraries. If you write your app using win32, you won’t be able to port is very easily. You’re also stuck with whatever bad or bizarre decisions Microsoft made. It’s even worse for CUDA. GPUs are expensive, and now you’re vendor locked. You’re between a rock and a hard place. Either spend millions in engineering time, or millions on price-gaug…
” If you write your app using win32, you won’t be able to port is very easily.”
This is wrong way around.
If you don’t support the platform your app runs on using the native api:s to the hilt your port is just bad.
If you actually want to support multiple platforms _you actually need to support_ them from the ground up.
This is speaking industrially and businesswise. A professional software business always has per-platform implementation resources. Or they have just one platform. Or they pretend they are multiplatform and then _everybody_ _daily_ fights with the problems this causes.
Obviously those elements that can be portable should be. It’s like Einsteins simplicity maxim - your codebase should be as portable as can be but not more.
” It’s even worse for CUDA…”
No these are just the business and market constraints. If this does not make sense for your offering then don’t use it. This feels like false FOMO - CUDA is not a silver bullet but it might be a specific solution to a specific problem.
Re: Nvidia announces native GPU programming in Rust
#196Earlier 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.
Platform may retroactively make up and enforce rules that makes your content violate terms (and remove them) See YouTube.
I certainly dislike how everyone on YouTube is saying “SA” and “unalive” and “corn”.
It’s one thing if it’s some funny commentary channel avoiding those words, but what bothers me is the true crime YouTubers. In the subject of true crime, rape and murder are just things that are probably going to come up, and when they refuse to use the appropriate language, it comes off as infantilizing, which is weird considering that my actual YouTube account is over 18, let alone the viewer using it.
Advertisers ruin everything, I guess.
Re: Nvidia announces native GPU programming in Rust
#197Earlier 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.
His kids were probably watching him type over his shoulder and he didn’t want to hear, “Daddy, what does crap mean?”
I am arguing that they would ask that anyway.
I guess I never understood censorship when it’s plainly obvious what you’re censoring. Anyone who can read will clearly know that it said “crap”, so I don’t see how it’s fundamentally different than just saying the word. You still put the word into my brain.
Re: Nvidia announces native GPU programming in Rust
#198Earlier quoted context omitted.
Nobody cares if kernels are written in Rust. Kernels were meant to be written in C, but if you want to go more high-level try Triton or a similar DSL that nicely abstract tile sizes etc.
That is exactly why OpenCL failed adoption, focusing on C, instead of being polyglot like CUDA.
SYCL is the natively polyglot counterpart, with practical implementations of it compiling down to the same sort of SPIR-V kernels as OpenCL. (OTOH, much of the current adoption on the open standards side seems to target the more widely supported SPIR-V compute shaders, via Vulkan compute.)
Re: Nvidia announces native GPU programming in Rust
#199Earlier quoted context omitted.
Yes but there are business costs to using high-level proprietary tools and libraries. If you write your app using win32, you won’t be able to port is very easily. You’re also stuck with whatever bad or bizarre decisions Microsoft made. It’s even worse for CUDA. GPUs are expensive, and now you’re vendor locked. You’re between a rock and a hard place. Either spend millions in engineering time, or millions on price-gaug…
I wonder which APIs you would use to port easily, because POSIX and Khronos aren't it either, as they are industry standards driven by companies where one has to pay for a seat at Open Group and Khronos offices.
There is no ”easy” porting.
Once this is accepted the rest becomes easier as you are not wasting time trying to find a silver bullet.
I mean it’s then ”just normal work”.
Re: Nvidia announces native GPU programming in Rust
#200Earlier quoted context omitted.
That is exactly why OpenCL failed adoption, focusing on C, instead of being polyglot like CUDA.
SYCL is the natively polyglot counterpart, with practical implementations of it compiling down to the same sort of SPIR-V kernels as OpenCL. (OTOH, much of the current adoption on the open standards side seems to target the more widely supported SPIR-V compute shaders, via Vulkan compute.)
Not really, first of all it is for C++, not the range of languages supported by CUDA.
Before SPIR was a thing in OpenCL, Khronos could not understand why anyone would care about anything else other than C99, or why supporting Fortran on GPUs was at all relevant.
Secondly, from the competition only Intel cares about SYCL with their own sugar on top, OpenAPI.
AMD hasn't cared one second about it.
You may mention Codeplay, which is anyway an Intel owned company since 2022.
As for Vulkan, it doesn't have neither the features, nor the tooling that CUDA enjoys, it is the usual putting up with using LEGOs from different brands, with various pin sizes, that is so common with Khronos.