Posted by nonmaskable 22 hours ago
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.
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.
Even now I wonder if I am allowed to type bitch here...
I guess we will find out.
I've never had texts censored by texting providers, they're not supposed to read texts in the first place (at least around here).
I grew up texting. But in the 90s any profanity filters could just be turned off in settings.
Youtube is a lot more guilty of it though, as well as demonetizing.
Leaves more to the imagination.
To have an unclosed asterisk replacing characters in a word? I've only ever seen that as a way to bypass censorship. This spans communications from people currently in their 40s down to 20.
(although it is a half-joke since it's definitely not a curse word imo)
I'll admit, it never once occurred to me that people might be using censored characters to provide more emphasis that a word is a swear, but I guess it does indeed do that, at least to the writer. Whether that comes across to the reader, and whether the writer cares that their intention was understood... I'm not so sure.
See YouTube.
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.
I do find it a little amusing, because commenters stopped criticizing my cursing the moment I started getting a good chunk of karma here. I remember in 2016 someone criticized me for using the term "shitposting"...I don't think I've gotten that kind of criticism since 2016 though.
Otherwise cr*p is just as good as crap, shit, horseshit, poopoo or such.
edit: * replaced with \* as HN interprets asterisks as formatting for emphasis. Thx latexr for informing me
(if a platform is serious about Bad Words for whatever reason (moral?) they would also forbid character replacements; ultimately it's the intent, not the word itself, that they try to steer with rules like that)
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.
I believe we'll be left to wonder.
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.
Ironic, seeing as that is an opinion about it. Also weird telling people in an online discussion forum not to have opinions.
Yes. And crap. Not in my code bases.
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.
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-gauged hardware.
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.
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”.
Is this still true? eg, Shopify saying porting is now easy so no need for abstractions.
I mean _it's just work_. You don't need to invent anything. Just do the work.
What _is_ hard is when people run after silver bullets to avoid all this work.
Because people who don't understand software decide it would be cheaper to implement something only once. Or someone who does not really understand what they are doing insists that same C++ code runs automatically on all platforms.
AI has given the software engineers permit from the beancounters to do the sane thing.
Good software development orgs _have always_ done proper per platform ports.
Also - there is nothing wrong in supporting only one platform as such!
I've never understood why we can't just expose the GPU ISA directly the way the CPU does. It's all getting compiled down at the end of the day so someone has to write a compiler for it either way. We'd be substantially better off IMO if it was all built directly into LLVM and then let middleware sort out the details.
Naturally plenty of folks rather use software that doesn't take advantage of the hardware they paid for.
CPUs manage this by changing the internal micro-architecture, but historically GPUs only needed to support a graphics API and used that abstraction layer to freely change the hardware.
From: https://docs.nvidia.com/cuda/cuda-programming-guide/01-intro...
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".
Shouldn't this be alleviated by the current code generation machines?
> 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.
Turns out when one isn't ideologically against something they aren't willing to put up with a lesser experience just for the cause.
i'm currently using vulkan, and HLSL via dxc. which should be portable but it's not.
apple refuses to support vulkan, and relies on moltenvk and there's a bunch of OS/hardware/driver differences no matter what you do, that you'll probably have to feature test for, and compile a few different versions of your code no matter what you do
i think if you're doing something that you don't have to distribute to customers, just picking one stack and getting locked in has some appeal.
it leaves you vulnerable to lockin. but, especially in the age of ai, "claude, port this to vulkan" seems like a good enough defense against that
Isn't that how CUDA code is normally written?
The disadvantages of writing them together are listed in the various parent posts. But some code authors really like the convenience of having the two in the same file.
And the Mojo standard library has been open source for over a year.
It’s all open source. Go check it out!
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.
Just today I was reading Stanley Druckenmiller’s op ed in WSJ. This dude is like 80 and has made billions of dollars, and he got Claude to write his op ed???
Unbelievable. And the tells are so obvious, yet people still love the Claude-like quips and odd grammatical choices that read like halfway asshole halfway mid-sentence confusion.
On a side note, Vulkan has extension to launch CUDA kernels: https://docs.vulkan.org/refpages/latest/refpages/source/VK_N...
But only for compute tasks. So, practically an alternative language to write compute shaders in.
Thank you NVIDIA - for once (not twice though - you've given us nothing but despair for Linux+GPU).