| ▲ | fg137 10 hours ago |
| > 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. |
|
| ▲ | Hendrikto an hour ago | parent | next [-] |
| > 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. |
|
| ▲ | infamouscow 6 hours ago | parent | prev | next [-] |
| Many software engineers forget they're employee of a business. |
|
| ▲ | worik 7 hours ago | parent | prev | next [-] |
| > Are win32 APIs proprietary? Yes. And crap. Not in my code bases. |
| |
| ▲ | josephg 7 hours ago | parent | next [-] | | 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. | | |
| ▲ | ux266478 7 hours ago | parent [-] | | 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." | | |
| |
| ▲ | fsloth 5 hours ago | parent | prev [-] | | 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 5 hours ago | parent [-] | | 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. | | |
| ▲ | fsloth 4 hours ago | parent | next [-] | | ” 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. | |
| ▲ | Asmod4n 3 hours ago | parent | prev | next [-] | | Win32 is the most stable abi on the Linux desktop. | |
| ▲ | pjmlp 4 hours ago | parent | prev | next [-] | | 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 4 hours ago | parent [-] | | 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”. | | |
| |
| ▲ | socalgal2 4 hours ago | parent | prev [-] | | > 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 an hour ago | parent [-] | | 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! |
|
|
|
|
|
| ▲ | jacobgorm 10 hours ago | parent | prev [-] |
| CUDA is not an API, CUDA is a language, so you cannot make that comparison. |
| |
| ▲ | pjmlp 4 hours ago | parent | next [-] | | CUDA is neither an API, nor a language, it is an ecosystem. | | |
| ▲ | fc417fc802 3 hours ago | parent [-] | | 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. | | |
| ▲ | pjmlp 3 hours ago | parent | next [-] | | 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. | |
| ▲ | dev_hugepages an hour ago | parent | prev | next [-] | | If i'm not mistaken, this already exists, and the assembly language here is called PTX https://llvm.org/docs/NVPTXUsage.html | |
| ▲ | imtringued 2 hours ago | parent | prev [-] | | 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. |
|
| |
| ▲ | esseph 10 hours ago | parent | prev [-] | | > 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... |
|
