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

81–90 of 139 posts

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

#81

Post by dahart »

gj_78 wrote: post #73
dahart wrote: post #69

Earlier quoted context omitted.

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

> It is not just another tool , it is the tool that is closest to hardware evolution.

This is an open source library that meets the C++ standard, which is designed and contributed to by many companies, not just nvidia. Like AMD and Intel, Nvidia does release some proprietary things that your complaints might apply to, but this is not one of them.

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

#82

Post by retrac »

sterwill wrote: post #34
kitd wrote: post #13

Earlier quoted context omitted.

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.

For a non-mythical example, the 2nd-gen Buick LaCrosse was originally named Allure in the Canadian market. Se crosser is Quebec French slang for "to masturbate" and "la crosse" is also a slang term for a swindle or rip-off.

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

#83

Post by dahart »

gj_78 wrote: post #71
dahart wrote: post #70

Earlier quoted context omitted.

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

With libcu++, Nvidia is not saying how or when software should be written. Because the library is meeting the C++ standard, it does exactly what you said you want, it allows any developer to write code for any GPU (or CPU!) The library is doing the thing you‘re asking for. AMD & Intel can support the same code with only namespace changes, using their own version, because it’s open and written to the open standard.

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

#84

Post by moonchild »

londons_explore wrote: post #22
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?

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

Yes, but GPU architecture changes very frequently.

Shaders from 15 years ago still work, but they're compiled on-the-fly to a GPU-dependent format. I expect you don't want to have to recompile an entire c++ stdlib every time you recompile your own code.

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

#85

Post by moonchild »

virgulino wrote: post #17
NullPrefix wrote: post #12

Earlier quoted context omitted.

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

Unix users have "cu". Do "man cu", if you are curious. I haven't played with "cu" since the UUCP email era. Good times.

Doesn't exist on my system, but is at https://linux.die.net/man/1/cu

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

#86

Post by geofft »

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?

Almost all of the time, they do it via just adding new features and not breaking old ones.

But yeah, GNU/Linux and Solaris both have symbol versioning as part of ELF (I'm not sure if other executable formats have it; it doesn't actually require very much out of the format). The approach, roughly, is that each symbol in the file is named something like "memcpy@GLIBC_2.2.5", and if you see symbol versions in the library you're linking against, you include those references. The dynamic linker is also smart enough to resolve unqualified symbols against some default version the library specifies. This is important for backwards-compatibility, for the ability for distros to add symbol versions when upstream doesn't have them yet, and for things like dlsym("memcpy") keeping working. When they make a backwards-incompatible change (e.g., old memcpy supports overlapping ranges, new memcpy does not promise to do the right thing and you need to use memmove instead), they add a new version (e.g., "memcpy@GLIBC_2.14"). Anything compiled against the newer library will reference the new version, but an implementation of the old version still sticks around for older functions.

And yes, there were older versions before libc.so.6 - libc.so.5 was used, I think, in the early 2000s, but they've avoided changes since then. (The approach used there is that you can install both of them on a single system, but "libc.so" symlinks to one of them, and that name is used when you compile code. When you run gcc -lfoo, it looks libfoo.so, but if the library has a header saying its "real" name, called its "SONAME", is libfoo.so.1, the compiled program looks for libfoo.so.1 and not libfoo.so.) Now you only have to have a single glibc version and it works with many years of updates.

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

#87

Post by jki275 »

gj_78 wrote: post #71
dahart wrote: post #70

Earlier quoted context omitted.

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

That doesn’t make any sense.

You’re free to write whatever you want. This is Nvidia providing interfaces to their hardware for those of us who don’t want to write them for ourselves.

It’s a gift. Take it or don’t. How in the world you can say Nvidia shouldn’t be allowed to write software for their GPUs makes no sense at all. Should the government stop them? Any developer can write anything they want - but Nvidia is obviously going to support their own hardware. How does it make any sense otherwise?

All code is “deprecated in the long term” for a long enough “long term”. That doesn’t equal useless. Your comment is nonsensical.

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

#88

Post by matheusmoreira »

lionkor wrote: post #47

> Promising long-term ABI stability would prevent us from fixing mistakes and providing best in class performance. So, we make no such promises. Wait NVidia actually get it? Neat!

This is an awesome quote... Same argument used by the Linux kernel developers.

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

#89

Post by gj_78 »

jki275 wrote: post #87
gj_78 wrote: post #71

Earlier quoted context omitted.

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

That doesn’t make any sense. You’re free to write whatever you want. This is Nvidia providing interfaces to their hardware for those of us who don’t want to write them for ourselves. It’s a gift. Take it or don’t. How in the world you can say Nvidia shouldn’t be allowed to write software for their GPUs makes no sense at all. Should the government stop them? Any developer can write anything they want - but Nvidia is o…

I have nothing against the library itself, rather the fact that it is made by the hardware provider. Good or not, It looks like a marketing goodie given away by the manufacturer.

History shows that hardware providers are not good at maintaining software at a high-quality level. Think of Sun/Sparc/Solaris or IBM/Power/Aix ... both excellent when it comes to hardware and loosers on the software side even after decades of development. It is simply not their "favorite stuff". Note that, linux, developed independently of Sun/IBM, is doing a good job.

There is probably a lot of nice improvements to do at the hardware level for Nvidia GPUs, not to let their engineers work on this kind of disposable software. Please, Nvidia, Let someone else make that software. As a customer, I only need the next release of that Good Old hardware GPU !!!

Post reply on HN