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

71–80 of 139 posts

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

#71

Post by gj_78 »

dahart wrote: post #70
gj_78 wrote: post #61

Earlier quoted context omitted.

Again, I see what you mean. I am even against nvidia advising the developers to use such or such C++ library (be it GNU). It is not their role to do that. We need smarter and more shining GPUs from nvidia, not software. I would say .... The hardware must be sold independently of the software ... but it is a bit too complex, I know.

I'm not understanding your point at all. You don't think developers should be able to write C++ code for the GPU? What do you even mean about 'it is not their role to do that.' and 'hardware must be sold independently of the software'?? Why are you saying this? Software interfaces are critical for all GPUs and all CPUs, just ask AMD & Intel. There is no such thing as CPU or GPU hardware independent of software. Plus,…

> You don't think developers should be able to write C++ code for the GPU?

To be clear, I don't think nvidia-paid developers should be able to write C++ Code for a nvidia-sold GPU. The world will be better if any developer (paid by nivida or not) is able to write code for any GPU (sold by nvidia or not). It is not nvidia role to say how or when software will be written. Their hardware is good and that's more than OK.

AI/CUDA code written specifically for nvidia is useless/deprecated in the long term. A lot of brain waste.

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

#72

Post by aronpye »

geofft wrote: post #42
MichaelZuo wrote: post #21

Earlier quoted context omitted.

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?

> Does any major software vendor support older versions of the ABI or machine code? Yes, this is extraordinarily common. The ABI is an interface , a promise that new versions of the machine code for a library can both be used by binaries compiled against the old one. There's new machine code, but there's no "by definition" of whether they make this promise or not. glibc (and the other common libraries) on basically a…

Excellent comment, I was wondering how glibc handled backwards compatibility.

Is symbol versioning an ELF object file thing, or is it more universal than that?

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

#73

Post by gj_78 »

dahart wrote: post #69
gj_78 wrote: post #62

Earlier quoted context omitted.

Sorry, related to cpu and host memory , I was wrong. I meant : having the GPU seller control/write code that plays with host cpu and memory is bad. Let people use their own gcc/g++ or whatever compiler and publish the specs. Unless they also start selling CPUs.

This is gcc or whatever compiler, it is not nvidia's compiler. This library does not give nvidia any "control" over host operations, it gives developers another tool. They did publish the specs, it's open source . BTW, Nvidia's acquisition of ARM means that it will be selling CPUs. P.P.S., the driver runs on the host, so your proposed alternative doesn't address the point you think you're making.

I did not say the library controls anything, Nvidia controls the library : its features, its roadmap, its bugs corrections, development efforts (people) etc. All these choices are made by Nvidia. It is not just another tool , it is the tool that is closest to hardware evolution.

Nvidia buying ARM is not a good news for me. The same way I don't like them making software, I also don't like them selling CPUs or seafood. They are good at GPUs and that's OK.

The drivers are usually running in the kernel space and do not involve much of interaction with users. Firmware, on the other side, is hardware-close software and can be gradually replaced by specific hardware continuous improvements without the user/software or the OS noticing.

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

#74

Post by einpoklum »

1. How do we know what parts of the library are usable on CUDA devices, and which are only usable in host-side code?

2. How compatible is this with libstdc++ and/or libcu++, when used independently?

I'm somewhat suspicious of the presumption of us using NVIDIA's version of the standard library for our host-side work.

Finally, I'm not sure that, for device-side work, libc++ is a better base to start off of than, say, EASTL (which I used for my tuple class: https://github.com/eyalroz/cuda-kat/blob/master/src/kat/tupl... ).

...

partial self-answer to (1.): https://nvidia.github.io/libcudacxx/api.html apparently only a small bit of the library is actually implemented.

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

#75

Post by einpoklum »

pjmlp wrote: post #33
scott31 wrote: post #4

A pathetic attempt to lock developers into their hardware.

The other vendors are to blame for sticking with outdated C and printf style debugging.

1. printf-style debugging is what we use on NVIDIA hardware too.

2. OpenCL 2.x allows for C++(ish) source code. Not sure how good the AMD support is though.

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

#76

Post by jcelerier »

aronpye wrote: post #72
geofft wrote: post #42

Earlier quoted context omitted.

> Does any major software vendor support older versions of the ABI or machine code? Yes, this is extraordinarily common. The ABI is an interface , a promise that new versions of the machine code for a library can both be used by binaries compiled against the old one. There's new machine code, but there's no "by definition" of whether they make this promise or not. glibc (and the other common libraries) on basically a…

Excellent comment, I was wondering how glibc handled backwards compatibility. Is symbol versioning an ELF object file thing, or is it more universal than that?

ELF: https://lists.debian.org/lsb-spec/1999/12/msg00017.html

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

#79

Post by pjmlp »

einpoklum wrote: post #75
pjmlp wrote: post #33

Earlier quoted context omitted.

The other vendors are to blame for sticking with outdated C and printf style debugging.

1. printf-style debugging is what we use on NVIDIA hardware too. 2. OpenCL 2.x allows for C++(ish) source code. Not sure how good the AMD support is though.

1. Ever heard of Nights and Visual Studio plugins?

2. OpenCL 2.0 was a failure, so OpenCL 1.2 got renamed as OpenCL 3.0. C++ bindings were dropped and SYSCL is now backend agnostic.

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

#80

Post by retrac »

quotemstr wrote: post #65
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...

There should be no expectation of C++ ABI compatibility. Do you want your system to be ABI compatible or do you want it to evolve? You can't have both. You have to pick one. I favor evolution.

A properly designed ABI is capable of expansion. The design risk is not so much being backed into a corner, as just accumulating a great deal of obsolete cruft over the years/decades.

Win32 is a great example of this. It has been extensively overhauled, and best practice for writing a new application today is quite different from 25 years ago, but unmodified Windows 95 applications still usually run correctly.

Post reply on HN