Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Libcu++: Nvidia C++ Standard Library

github.com

Post reply on HN
Print view View original

31–40 of 139 posts

Re: Libcu++: Nvidia C++ Standard Library

#31

Post by my123 »

jpz wrote: post #9
scott31 wrote: post #4

A pathetic attempt to lock developers into their hardware.

They seem to be pushing the barrier on innovation on GPU compute. It seems a little unfair to call that pathetic, whatever strategic reasons they have to find OpenCL unappetising (which simply enables their sole competitor in truth.) Their decision making seems rational, of course it's not ideal if you're consumer. We would like the ability to bid off NVidia with AMD Radeon. Convergence to a standard has to be driven…

With nvc++, they are converging towards a standardised source code standard: https://developer.nvidia.com/blog/accelerating-standard-c-wi...

However, this notably doesn't cover binaries, which are GPU vendor specific in that case, so AMD for example would have to provide a C++ compiler implementing stdpar for GPUs targeted to their hardware.

Re: Libcu++: Nvidia C++ Standard Library

#32

Post by my123 »

MichaelZuo wrote: post #21
fanf2 wrote: post #14

“ Whenever a new major CUDA Compute Capability is released, the ABI is broken. A new NVIDIA C++ Standard Library ABI version is introduced and becomes the default and support for all older ABI versions is dropped. ” https://github.com/NVIDIA/libcudacxx/blob/main/docs/releases...

It’s interesting that they use the word to broken to describe incompatible machine code. Well if the code is recompiled for each new version then it’s different from the old machine code, that’s by definition. Does any major software vendor support older versions of the ABI or machine code?

Note here that your binaries will continue to run even on future driver versions - and future hardware - that's what PTX is for, as the standard libraries are statically linked in.

It's just your object files that aren't compatible, so that you can't mix and match libraries built with different CUDA versions into the same binary.

Re: Libcu++: Nvidia C++ Standard Library

#34

Post by sterwill »

kitd wrote: post #13
NullPrefix wrote: post #12

Earlier quoted context omitted.

This only affects developers. Limited scope. Wasn't there something related about Microsoft Lumia phones?

cf. the Vauxhall Nova car "No va" means "doesn't go" in Spanish.

I think it's unlikely that Spanish speakers would have been confused about the word "nova" when used as a car name. In Spanish "nova" describes the same astronomical event we call a "nova" in English: a new light in the sky. Additionally Spanish "nuevo" and English "new" seem to share the same root. My point is these words all mean similar things to English- and Spanish-speaking car buyers.

Re: Libcu++: Nvidia C++ Standard Library

#35

Post by londons_explore »

formerly_proven wrote: post #29
londons_explore wrote: post #22

Earlier quoted context omitted.

Famously Microsoft does with Windows. That's how an exe file from 25 years ago can still run today.

Running 32 bit x86 code on a AMD64 machine is possible on most operating systems which supported both of these, and has probably more to do with AMD64 supporting that execution model.

Try that on Linux and you'll find most libraries no longer have the same entry points and that various data structures have changed leading to fun fun crashes...

The kernel itself has maintained (mostly) ABI compatibility though.

Re: Libcu++: Nvidia C++ Standard Library

#36

Post by gj_78 »

my123 wrote: post #30
gj_78 wrote: post #26

Earlier quoted context omitted.

Agree++. They are good at hardware and should stay that way.

The thing is: that hardware isn't very usable without good software, and an easy to use software stack at that. That's what NVIDIA understood and made them what they are today.

A lot of hardware has builtin software, either inside a firmware or as a driver. Keeping the software part in firmware lets customer free to use any kind of OS. Using host cpu and memory is bad design IMHO.

Re: Libcu++: Nvidia C++ Standard Library

#37

Post by my123 »

gj_78 wrote: post #36
my123 wrote: post #30

Earlier quoted context omitted.

The thing is: that hardware isn't very usable without good software, and an easy to use software stack at that. That's what NVIDIA understood and made them what they are today.

A lot of hardware has builtin software, either inside a firmware or as a driver. Keeping the software part in firmware lets customer free to use any kind of OS. Using host cpu and memory is bad design IMHO.

> Keeping the software part in firmware lets customer free to use any kind of OS

Raspberry Pi initially shipped with such a graphics stack, with the Arm side just being a communication driver in the kernel and an RPC stack in user-space.

It isn't a good idea (for numerous reasons, including security) and is even more closed in practice than what ships today.

Re: Libcu++: Nvidia C++ Standard Library

#38

Post by gj_78 »

my123 wrote: post #37
gj_78 wrote: post #36

Earlier quoted context omitted.

A lot of hardware has builtin software, either inside a firmware or as a driver. Keeping the software part in firmware lets customer free to use any kind of OS. Using host cpu and memory is bad design IMHO.

> Keeping the software part in firmware lets customer free to use any kind of OS Raspberry Pi initially shipped with such a graphics stack, with the Arm side just being a communication driver in the kernel and an RPC stack in user-space. It isn't a good idea (for numerous reasons, including security) and is even more closed in practice than what ships today.

Raspberry Pi is not marketed for graphics as nvidia is doing with their GPUs. What I mean is that firmware is running on a usually small cpu and memory that is sold as a part of the GPU. No security issues here as the main security issue is to plug the whole GPU inside your PC.

Re: Libcu++: Nvidia C++ Standard Library

#39

Post by formerly_proven »

londons_explore wrote: post #35
formerly_proven wrote: post #29

Earlier quoted context omitted.

Running 32 bit x86 code on a AMD64 machine is possible on most operating systems which supported both of these, and has probably more to do with AMD64 supporting that execution model.

Try that on Linux and you'll find most libraries no longer have the same entry points and that various data structures have changed leading to fun fun crashes... The kernel itself has maintained (mostly) ABI compatibility though.

That's a "you're holding it wrong" problem, though. Projects like GTK or Qt never claimed they'd be backwards-compatible 26 years (Qt has specific backwards-compatibility API and ABI guarantees and are in my experience pretty diligent about it), so if you want a binary to work for a long time, you have to ship your own versions of these. Libraries like Xlib on the other hand are very stable and much more similar to the Win32 API in that respect. In theory Linux has versioning for libraries, in practice it is never used correctly and useless anyway, since distros generally only keep around one version of everything, so even if you'd link against a specific version (e.g. libfoobar.so.2.21 instead of libfoobar.so.2, which will break if you don't recompile and/or patch the source), it wouldn't exist _anyway_ after a few updates. And that's mostly because distros never promised you'd be able to run binaries built outside their packaging infrastructure anyway; it being common practice and sometimes working doesn't imply it's guaranteed to work.

Hence why C applications only linking these "basic" libraries (libc, Xlib, zlib, ...) are regarded as so stable and portable, because they're built and linked against system components which rarely change. (Keep in mind to build this kind of binary on ancient systems, otherwise glibc will make sure it won't work everywhere).

Re: Libcu++: Nvidia C++ Standard Library

#40

Post by XorNot »

formerly_proven wrote: post #39
londons_explore wrote: post #35

Earlier quoted context omitted.

Try that on Linux and you'll find most libraries no longer have the same entry points and that various data structures have changed leading to fun fun crashes... The kernel itself has maintained (mostly) ABI compatibility though.

That's a "you're holding it wrong" problem, though. Projects like GTK or Qt never claimed they'd be backwards-compatible 26 years (Qt has specific backwards-compatibility API and ABI guarantees and are in my experience pretty diligent about it), so if you want a binary to work for a long time, you have to ship your own versions of these. Libraries like Xlib on the other hand are very stable and much more similar to t…

This is one of those things it feels like all the content addressable initiatives should be able to solve somehow. With near ubiquitous internet access, why can't a program ship with a list of standard library hashes it'll link against and my distro go fetch them from IPFS or whatever if they're not local.
Post reply on HN