Hacker News Reader

Comment by fg137 | Hacker News Reader

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

View on HN

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

You're interpretation is selectively literal in order to be rhetorical.

Where do you think you are ?

Most of us are in tech/IT/research the population in the spectrum here is orders of magnitude bigger than the avg on real life. SO yeah people will be literal in order to be rhetorical. Not even selectively, this is the one site where you NEED to use /s unironically.

That opinion is work-ethic related, not CUDA-related. The stance is reasonable too; why complain about characteristics of CUDA that can't be changed?

Your job as a CUDA engineer isn't to decide whether or not a proprietary API/compiler is the right call. Your boss made that choice for you when they hired you, and you accept the tradeoff if you want to keep working there. It's like someone protesting Dotnet because they wish they spent the rest of their life working with Perl instead. You can do that, but it's a completely different job with different pay grades and demands.

A pedantic dissection of someone saying "why get worked up about it".

Many software engineers forget they're employee of a business.

If that business makes it money selling a cross-platform AI inference engine, as was the case for my previous startup, it is bad business to tie yourself to single platform. I managed to build a single code base that would support CPUs, OpenCL, Metal, CUDA, D3D12, and WebGPU from a single set of kernel sources. As a single developer, there was no way I would have been able to, at the time, maintain separate code paths and GPU kernels for each of those platform, in addition to training the models etc.

> It's just part of business. I don't see how it's worth having any emotions or opinions about it.

Because we're engineers? Hackers? You know, hacker news?

We're supposed to care about the craft, its quality, and our long-term interests, not the shareholders, not the executives, and definitely not Microsoft and NVIDIA. If you really think this isn't a discussion worth having then you don't belong in this domain at all and you shouldn't be an engineer.

> People have been doing that all the time for every kind of codebase. It's just part of the business.

What is your ecosystem where this is true? Embedded or industrial, maybe?

I'm guessing you assume other people also use the same windows or embedded systems you're referring to. That's an insane thought: nobody would use this if they had any chance, and you intentionally chose this misery.

Obviously, you don't need to live this way. You can be free. Breathe.

> It's just part of the business. I don't see how it's worth having any emotions or opinions about it.

It's called foresight. The ability to see that vendor lock-in is against our long-term interests.

Your windows comparison is apt - now we have tons of software tied to windows, making it hard to leave that spyware-infested OS.

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

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?

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

https://blog.hiler.eu/win32-the-only-stable-abi/

If I recall correctly, the Golang team got bitten by this on MacOS.

They initially implemented the Golang runtime directly on top of MacOS syscalls (not the C runtime library), just like they did on Linux - and then those syscalls changed, breaking Golang.

They had to switch to the official stable API which on MacOS is the C runtime library, not syscalls.

> This isn’t even close to being true. Here’s a thing I did that made things way more complicated than is worth it for 99% of developers when there is a proprietary solution made so I do not need to worry about these things. Because it is so hard to work around it, it is entirely pointless to develop for one of the most used operating systems in the world.

Just being totally honest this is how I read this comment when I insert context that seems important to me. I respect having principles but at some point there needs to be more value in practicality over your codebase not being locked into a proprietary framework at all.

> Not even close to being true. You can invoke syscalls directly,

The windows syscall API is yet another proprietary windows API. Sure - you can call it without loading any DLLs. But you're still calling into a proprietary windows API.

If you really hate calling proprietary windows APIs that much, maybe stop developing for windows? Develop software for linux. Or make your own kernel, or whatever. But if you keep developing software for windows, stop fighting it. Unless you have a very good reason, your software should try to fit in on its host platform. It should behave well, and work like other windows software.

It's like travel. If you fly to France, try to fit in. Maybe learn a bit of French before you go. If you hate France, don't go.

That’s insane. Windows does not have a stable syscall ABI. The way you’re supposed to interact with the kernel is through the userspace library. Of course the kernel team refuses to cooperate.

Do you want to keep reverse engineering the syscall ABI for every Windows edition and update ever? Do you want to ask your users to disable Windows Update?

Regardless, I don’t even understand how that’s relevant, since you’re still introducing a dependency on a proprietary ABI.

> If you're going to make apps in windows

...your troubles are starting

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.

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.

The hard part of porting to a different platform is usually not the instruction set. It’s the OS and system abstractions.

For example, if you have a program that just does raw math and pointer arithmetic and data structure manipulation —- that is, pure computation — then porting it to a different CPU might well be trivial. Just recompile. As long as your language toolchain supports it, this will Just Work.

But if your program works with the filesystem and sockets and threads, then it’s less likely to work. This is the promise of POSIX: if your program uses only what’s offered by the POSIX standard and uses those functions correctly, then it’s supposed to work on any POSIX-compliant system. Just recompile.

But if your program has a GUI, or does 3D graphics, or uses special methods for high-performance networking, or accesses gyroscopes or accelerometers or touch sensors, well then you have to do work to port. And notice that this work isn’t about which CPU instruction to use. It’s about figuring out —- deciding —- what the right thing to do is, for your app, given a slightly different set of available system capabilities.

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

It really depends on the application. The reason web is so successful as a platform is because it’s rich enough for most applications, and inherently cross-platform at an OS level.

And Re: CUDA: yes if it doesn’t make sense then dont use it. That’s sort of my whole argument. It might make some level of sense from a technical perspective, but that needs to be balanced with business risk. I’m saying a lot of people aren’t doing the balancing right, which is why these new tools have value.

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?

> only seems stable, but internally it changes

That's literally the definition of it being stable. Programs written against an interface keep working despite the implementation changing. The Linux kernel also constantly changes internally but programs written against syscalls keep working, so it is stable; that fact doesn't stop being a fact just because I dislike perf_event_open(2) or whatever. This is all very basic and easy to understand.

Those are not a part of the API contract in case with NT kernel, though, unlike Linux.

Also, there are OS-provided shims in ntdll.dll (which, by the way, isn't a part of Win32 platform API, but a part of the NT kernel interface).

Correct, most of Linux user land targets API stability, not ABI stability. Windows targets ABI stability because applications are typically distributed as binary blobs. Most applications on Linux are open-source and built per each distro, so it’s a non-issue, just recompile.

This doesn’t work for proprietary software that’s distributed as blobs and rarely updated, like say, video games. But that’s a minority of stuff on Linux. But not on windows.

Realistically, on Linux applications target specific API versions of frameworks. Like Qt 6, or GTK 3, or whatever. Then everything is compiled or dynamically linked at a per-distro level. The ABI compat can bite specifically when distros enforce strict dynamic linking. But then containerization technologies come in.

And there is a difference between API and ABI stability. For example, adding SSO to std::string in C++ broke ABI, not API. If you recompile it’s fine, everything works. If you don’t then it doesn’t.

Sadly glibc made the choice for everyone that you have to recompile constantly to keep your app working.

That’s one of the biggest issues keeping Linux small on the desktop since nearly no commercial oriented company works that way.

But it looks like we will soon be able to „virtualize“ the dynamic loader so glibc has no say in this matter anymore.

I can program all my non-CUDA GPUs use completely open non-proprietary toolchains. And if that ceases to be the case on one platform I can switch platforms without having to rewrite all my code.

CUDA is not an API, CUDA is a language, so you cannot make that comparison.

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

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.

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.

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.

Can't the same also be said of much of the x86 vocabulary at this point?

I appreciate that we can upload SPIR-V directly. The API still feels overly obtuse but it's not so bad.

SYCL gets close but is language specific.

> I don't see how it's worth having any emotions or opinions about it. Seems like you are wasting your energy.

Some people only care about the easiest path to their pay check. Some people actually care about software engineering. I tend to prefer the latter but hamstrung by the former.

Have you considered that maybe, just maybe, you can have both an easy path to your paycheck and care about software engineering? You also might have an incorrect definition of "software engineering" in mind

Reply on news.ycombinator.com