3 ms·

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 concep

by fsloth 9d ago

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.

preg_match 9d ago
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.
- pjmlp 9d ago
  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.
  - fsloth 9d ago
    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”.
    - pjmlp 9d ago
      Exactly.
- socalgal2 9d ago
  > 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.
  - fsloth 9d ago
    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!
    - DeepSeaTortoise 9d ago
      > 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.
      - articulatepang 7d ago
        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.
- fsloth 9d ago
  ” 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.
  - preg_match 9d ago
    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.
- Asmod4n 9d ago
  Win32 is the most stable abi on the Linux desktop.
  - rfgplk 9d ago
    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.
    - david-gpu 9d ago
      >> 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?
    - aseipp 9d ago
      > 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.
    - usernameak 9d ago
      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).
  - preg_match 9d ago
    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.
jacobgorm 9d ago
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.

by fsloth 9d ago

preg_match 9d ago

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.

pjmlp 9d ago
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.
- fsloth 9d ago
  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”.
  - pjmlp 9d ago
    Exactly.
socalgal2 9d ago
> 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.
- fsloth 9d ago
  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!
  - DeepSeaTortoise 9d ago
    > 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.
    - articulatepang 7d ago
      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.
fsloth 9d ago
” 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.
- preg_match 9d ago
  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.
Asmod4n 9d ago
Win32 is the most stable abi on the Linux desktop.
- rfgplk 9d ago
  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.
  - david-gpu 9d ago
    >> 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?
  - aseipp 9d ago
    > 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.
  - usernameak 9d ago
    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).
- preg_match 9d ago
  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.

jacobgorm 9d ago

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.