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 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.
Because I know it is not technically crap, a lot of competent people worked on it, most with good intentions. I suppose it is better described as a cleverly designed Trojan horse than can infect your software and make that software become crap, in the sense that it becomes harder to maintain, increases code duplication, messes with your build system, ties your build system to platforms that have their toolchain binaries available, etc., etc., without bringing any long-term benefits over learning things the hard way.
I thought that cp*p is some kind of ugly cuda pointer declaration :D And being non-standard C++ syntax it wouldn’t compile.
Because nanny states are tracking your keyboard nowadays.
Normative behavior has shifted due to pervasive censorship and surveillance.
* is used to give emphasis and show that they are using the word as curse word rather just calling it bad
It doesn't read as emphasis to me. It reads like the person is trying hard not to curse, and they think "crap" is a curse word. It's a little bit adorable, like I'm reading a comment from an obedient child.
I guess you are not from the generation of texters. This how languages work we used to use * as a way to avoid getting censored it over time became a way to curse or give emphasis.
I'm definitely from the generation of texters and there was never any censorship going on with SMSs... yours must be a cultural or regional thing.
Maybe you didn't have T9 enabled but I consider it censorship when I type bitch and it gives me chubi.
Even now I wonder if I am allowed to type bitch here...
I guess we will find out.
But typing "b*tch" with T9 is just as difficult (if not more) as typing "bitch". Anyway, I guess I never had a need to swear much over SMS. On IRC, on the other hand...
Am I, with around 30, in this generation? Putting * in words seems like self censorship to me. Still, might have a cultural component. German here.
It can be used for in-jokey comedic effect. For example, referring to M*cr*sft W*nd*ws or Br*dc*m as though they were offensive terms. Or *r*cl*.
I'm in my 40s and * is self-censorship to me. It must be a cultural thing.
Is that a cultural/national thing instead of an age thing?
I've never had texts censored by texting providers, they're not supposed to read texts in the first place (at least around here).
Sounds like a generational thing.
I grew up texting. But in the 90s any profanity filters could just be turned off in settings.
People are getting used to censor themselves in order not to be reported, banned, or «hurt » other sensibilities. The words « rape » couldn’t be written in instagram for example, what a great way to deal with such a serious issue. Mainly an American thing spreading away from young people if you ask me. Sorry America, just being honest here.
America is partly guilty, but TikTok censorship is a big part of the younger generation's tendency toward self censorship.
As much as I personally dislike TikTok, I don't think it is fair to it: cultural willingness for more sensor sheep on Internet started years before TikTok's popularity in the west.
It's not the sole cause, but I believe it's the main driver behind a bunch of specific substitutions that are mainstream now or nearly so. For example, dih, ahh, and unalive. They may not have been invented on tiktok, but that's where they incubated.
There's no such censorship on TikTok, it's entirely groupthink based on people saying "when I use that word my video is seen less so therefore it's being censored".
Youtube is a lot more guilty of it though, as well as demonetizing.
How is that not a form of censorship? It is direct suppression of certain forms of speech.
YouTube has its problems but I don't think it's had quite as strong of an effect on language.
well_ackshually, tik tok has a well known, long, and rich history of suppressing certain search keywords.
After reading through the threat here it seems more like a cultural thing. The US has quite a lot of filters for profanity. I remember from my youth that in 2009 Eminem was a guest in a Germany TV show and very happy to swear as much as possible without being censored. https://www.youtube.com/shorts/2OC-yKZ5Yag
You had profanity filters for SMS?
I’ve been texting since it was first a thing (sms on Nokia phones) and no one I knows does this. We just say shit, fuck, and crap.
stop feeding nonsense to the masses
I think a string of non-alphanumeric characters would work much better here, like "Once you have allowed that proprietary @#$&% into your C++ codebase”
Leaves more to the imagination.
In any context I've seen, asterisks are for wrapping formatting and said formatting it to add emphasis. So being in the habit of typing `emphasised phrase`, for italics - regardless of whether the platform parses markdown/similar formatting, e.g. SMS.
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.
i do this to put emphasis, i always type "h*ck".
(although it is a half-joke since it's definitely not a curse word imo)
like for example, c*nt?
Maybe more like p**p, as in "that cunt p**ped in my yard"?
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.
What about ^#%& as was traditional in newspaper comics strips?
How about "Pockmark!... Freshwater swabs!... Bully!.." or "Amoeba! Bashi-bazouks! Chowderheads! Certified Diplodocuses! Nyctalop! Ectoplasm!"?
I was so disappointed when I tried reading tintin in other languages and found the dear captain was straight up using slurs in those. I wonder whether the english language ones have been edited over the years to remove that sort of thing
"Your mother was a hamster and your father smelt of elderberries!"
Known as grawlix or obscenicon.
https://en.wikipedia.org/wiki/Grawlix
Hah. Yeah, I agree. It's one of those things I admit is `lost in translation` for sure.
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.
I don't think those filters are even real, I think it's just mass-hysteria. I call these kinds of behaviours "traditions", but I'm not sure if there's a better term for it.
Basically someone comes up with something which is nonsensical, but plausible. Like believing that their videos are unpopular because they said the word "rape" and the algorithm magically got them, rather than because their videos suck. Then someone else sees that and starts thinking it is true. It silently spreads across the population.
I've seen this in organisations, where new recruits haven't been properly trained. Someone has come up with a method which is wildly incorrect and illegal, but plausible. The other new people around them have copied them. They've become slightly more experienced people, they've taught the next round of new people.
Before you know it, half of the organisation is doing something hilariously wrong, and they all sincerely believe it is the right way of doing it, because everyone does it. It's just self-reinforcing at that point.
I am sure they are bullshit. Like when they mute cursing and "risky" speech, but when you enable autogenerated subtitles they show up there. Youtube knows what thay said regardless if it's censored or not. It's so fucking stupid
It's become so bad that even quality history youtube channels are frequently using euphemisms like "moustache-man" instead of just saying "Hitler", to avoid their videos being buried by The Algorithm, and therefore cut severely into their viewership.
> even quality history youtube channels are frequently using euphemisms like "moustache-man" instead of just saying "Hitler"
That can be quite confusing. You had German mustache-man, Russian mustache-man, French mustache-man (Petain), French small-mustache-man (de Gaulle), Spanish small-moustache-man (Franco)
I think it's a win-win. Intelligent people easily knows what they're talking about, and the others don't get offended. /s
glad i found that /s at the end
It may be to bypass censorship, rather than self-censorship. Some platforms block or shadowban comments with curse words. Not sure about this platform.
HN definitely doesn't give a crap about that word.
I have written many words far worse than "crap" on this site. I haven't gotten in trouble over it yet.
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.
Back then the term was still associated with 4chan.
They dont like "seppo" for some reason.
can confirm, looks like crap is not on a list
pretty crappy list
cause you might go to the eternal flames if you say a no-no word online
Your comment only makes sense in context if you believe in a deity who is too dumb to understand the difference between cr*p and crap. I for one do not worship a Bayesian spam filter.
[dead]
IMO cr*p and crap are both valid but separate swear words. People have a wide option to choose from when they want to swear, and people like variety (much much more than LLMs do). People also tend to influence each other with their usages: cr*p is popular because it is popular.
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
To use a literal asterisk on HN, do ** or \*. Your single usage in two places instead turned the majority of the post italic.
His kids were probably watching him type over his shoulder and he didn’t want to hear, “Daddy, what does crap mean?”
"Daddy, what does cr*p mean?" Kids aren't stupid and this self-censorship isn't protecting anyone from anything.
(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'd consider that a joke - but also zero issue using any words talking in front of kids. You might wish to explain them anyways.
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.
What if a toddler is browser HN and sees the curse word?
My guess is that jacobgorm will not reply. I would love a reply, because I want to understand how others think.
I believe we'll be left to wonder.
> 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.
> 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.
Oh, does that mean I get to say you're ironic because, literally, they didn't tell anyone to do anything. They said they didn't understand the worth of the opinion. You're interpretation is selectively literal in order to be rhetorical.
Does that mean someone else gets say I'm being ironic because I'm selectively literal in order to be rhetorical? Well, okay, I guess it's harder now.
Many software engineers forget they're employee of a business.
> Are win32 APIs proprietary?
Yes. And crap. Not in my code bases.
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.
> 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 kernel/open windows etc. Fully statically linked, no libc, no win32, compiled on Linux executed on Windows.
The problem is this isn't really well documented _at all_, and I even ended up attempting to get in touch with the Windows kernel dev team to give me the actual internal syscalls/endpoints, but they refuse to cooperate. Which is why writing anything for Windows is entirely pointless.
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 your app to be portable across different OS versions, past and future, you'd better not.
Incidentally, syscalls would also break Wine. The way Wine works is basically by shipping their own versions of Windows DLLs, which express their operations in terms of Linux APIs. Because Windows programs don't rely on syscalls, and call all system functions via the system-provided libraries, the Wine loader can just link Wine's version and let the program work normally.
Find a way to get ring 0 without touching any system APIs and you can just make your own APIs. My programs shall never say "please."
Your programs shall never grace my systems.
What makes you think he'll let you have a say in this? Btw, you wanna buy some ~~dea~~ usb sticks?
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-gauged hardware.
” 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.
Win32 is the most stable abi on the Linux desktop.
Dead wrong. Win32 (externally) only seems stable, but internally it changes between Windows releases. Win7 syscalls are completely different from Win11 syscalls, meaning if I want to release a binary _without relying_ on Win32 I need to provide full syscall mappings _for each and every Windows version_. This doesn't happen on Linux.
>> Win32 is the most stable abi on the Linux desktop.
> Dead wrong [...] if I want to release a binary _without relying_ on Win32
Then you are not using the Win32 ABI, are you?
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”.
Exactly.
> If you write your app using win32, you won’t be able to port is very easily.
Is this still true? eg, Shopify saying porting is now easy so no need for abstractions.
Porting has never been hard. Just follow the platform guidelines. Make sane architecture. Done.
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!
> Good software development orgs _have always_ done proper per platform ports.
I really wonder why this was never fundamentally fixed. How performant a certain instruction on a specific platform is, how well it is supported and potential equivalents or sets of other instructions to emulate an equivalent are usually all very well understood.
So there should be some graph of operations which can transform any software from and to the specifics of each platform. Especially because firmware + compliers + platform abstracting libraries are basically already just that graph, although (usually?) to lossy to be applied in reverse. Add the recent developments in very large scale statistics to it and it'd probably be quite possible to transform from and to generic intent in the implementation to the uniqueness of each platform. E.g. the theming differences between a MacOS UI and a terminal application served over serial or the processing capabilities of a VLIW CPU compared to a FPGA or a GPU server.
Considering the enormous amount of work that went into compilers, better debugging and intermediate representations it seems like a huge missed opportunity nobody seriously asked the question whether information could be emitted that would allow for decompiling all the way back to the generic intent.
CUDA is not an API, CUDA is a language, so you cannot make that comparison.
CUDA is neither an API, nor a language, it is an ecosystem.
That's a nice way of saying that it's a dependency clusterfuck.
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.
Because even CPUs rather use JIT runtimes to deal with the various kinds of ISAs that exist.
Naturally plenty of folks rather use software that doesn't take advantage of the hardware they paid for.
If i'm not mistaken, this already exists, and the assembly language here is called PTX
https://llvm.org/docs/NVPTXUsage.html
PTX is a bytecode format, the CUDA driver JIT compiles it when uploading into the cards.
That would require vendors to either stick with a single backwards compatible ISA like intel did for x86 or document how their graphics cards work.
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.
> The CUDA runtime is a special case of one of the libraries provided by the CUDA Toolkit. The CUDA runtime provides both an API and some language extensions to handle common tasks such as allocating memory, copying data between GPUs and other GPUs or CPUs, and launching kernels. The API components of the CUDA runtime are referred to as the CUDA runtime API.
From: https://docs.nvidia.com/cuda/cuda-programming-guide/01-intro...
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".
> 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.
I meant LLMs :-)
You are trying to say that llm can replace compiler?
> 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,
Yes, I also prefer doing it that way, but in Cuda with the driver API. Allows you to handle kernels like shaders, including editing and hot-reloading at runtime.
The reason I'm sticking with CUDA is because it's by far the most convenient API to use, without nonsense like 50-liners to alloc memory or the need to manage descriptors, bindings, queue families, etc.
> The reason I'm sticking with CUDA is because it's by far the most convenient API to use, without nonsense like 50-liners to alloc memory or the need to manage descriptors, bindings, queue families, etc.
I was there when the OpenCL committee was deciding on that sort of stuff.
As I recall, and it's been two decades and a lot of sleepless nights since then, there was real pushback at the time against OpenGL-style default bindings. So folks didn't want to establish an implicit command queue or any other default objects attached to other objects. Part of it is because OpenGL was perceived as clumsy and passé, some of it was because it is not friendly to multi-threaded applications.
Those first meetings were a shitshow full of tension, implicit threats from Apple, and backroom deals. Kudos to Neil Trevett for chairing the group; I I bet it wasn't fun for him either.
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.
People that attack proprietary APIs always miss the point why most devs outside FOSS circles prefer them.
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 know it's not the same thing because proprietary vs open software it's way less important but, generally if you are not ideologically against something you can easily follow the stream and do lot of nefarious actions, especially if the action has enough degrees of separations from the actual nefast outcome.
from what i can tell, you're going to be stuck with that no matter what you do
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
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.
> 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?
No. CUDA allows you to write all the code in a single file, and uses a preprocessor to split it back out and pass it through separate compilers, one for host and one for device.
This true, but you can write the two separately if you want.
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.
You could also use Mojo, one language for all targets.
Or julia if you want a much more mature ecosystem.
I highly recommend Julia for (scientific) GPU programming but it would be nice if there was a larger community and/or funding behind the GPU side of things. It has very few core devs for what it is.
I began to lose interest after the acquisition. Have you been following along, are they still going to open source it?
The Mojo compiler has been open source for over a month now.
And the Mojo standard library has been open source for over a year.
It’s all open source. Go check it out!
Nice, thank you. There is an old python project I've been thinking about converting to Mojo.
I thought they already did and released the compiler source code under Apache 2.0.
Anyone here looking at Modular's offerings?
What is a proprietary crop?
It's actually creep.
? I find it hard to see the issue here. Just put it in a separate file and call it?
Is this satire? D3D12 and Metal aren't any less proprietary than CUDA.
You can call their APIs without needing to compile your code with a proprietary compiler or adopt a bastardized version of C++.
yeah, just write a stub/wrapper around it and abstract. it's the classic coupling problem. nothing to do with CUDA
[flagged]
[dead]