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

41–50 of 139 posts

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

#41

Post by my123 »

gj_78 wrote: post #38
my123 wrote: post #37

Earlier quoted context omitted.

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

With the complexity of GPU driver stacks, what you are asking for is not firmware, but a multi GHz+ set of CPUs just for that purpose.

+ RPC needed all the time... with its latency would tank the performance

It'd also be not tinkerable at all unlike what we have today, it's exactly advocating for the opposite of open.

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

#42

Post by geofft »

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?

> 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 all the GNU/Linux distros does this: that's why it's called "libc.so.6" after all these years. New functions can be introduced (and possibly new versions of functions, using symbol versioning), but old binaries compiled against a "libc.so.6" from 10 years ago will still run today. (This is how it's possible to distribute precompiled code for GNU/Linux, whether NumPy or Firefox or Steam, and have it run on more than a single version of a single distro.)

Apple does the same thing; code linked against an old libSystem will still run today. Android does the same thing; code written to an older SDK version will still run today, even though the runtime environment is different.

Oracle Java does the same thing: JARs built with an older version of the JDK can load in newer versions.

Microsoft does this at the OS level, but - notably - the Visual C++ runtime does not make this promise, and they follow a similar pattern to what Nvidia is suggesting. You need to include a copy of the "redistributable" runtime of whatever version (e.g. MSVCR71.DLL) along with your program; you can't necessarily use a newer version. However, old DLLs continue to work on new OSes, and they take great pains to ensure compatibility.

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

#43

Post by geofft »

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.

Customers either didn't make that association or didn't care: https://www.snopes.com/fact-check/chevrolet-nova-name-spanis...

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

#44

Post by dahart »

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.

Can you elaborate on what you mean? This is an open source library for developers to write code that can compile without changes on both CPU and GPU. This solves a problem that can’t be solved in firmware, and this is not a case of nvidia using cpu and host memory - whether to use cpu and host memory is strictly up to the developer.

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

#45

Post by dahart »

gj_78 wrote: post #24

I really do not understand why a (very good) hardware provider is willing to create/direct/hint custom software for the users. Isn't this exactly what a GPU firmware is expected to do ? Why do they need to run software in the same memory space as my mail reader ?

What do you mean about running in the same memory space? Your operating system doesn’t allow that. Is your concern about using host memory? This open source library doesn’t automatically use host memory, users of the library can write code that uses host memory, if they choose to.

How would a firmware help me write heterogeneous bits of c++ code that can run on either cpu or gpu?

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

#46

Post by kortex »

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.

That sounds like vendor binary blob sdk libraries, only everything is an rpc and you're not even in the same memory space, aka distributed computing, except you have no control over the device stack. Sounds kinda awful to me.

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

#48

Post by gj_78 »

dahart wrote: post #45
gj_78 wrote: post #24

I really do not understand why a (very good) hardware provider is willing to create/direct/hint custom software for the users. Isn't this exactly what a GPU firmware is expected to do ? Why do they need to run software in the same memory space as my mail reader ?

What do you mean about running in the same memory space? Your operating system doesn’t allow that. Is your concern about using host memory? This open source library doesn’t automatically use host memory, users of the library can write code that uses host memory, if they choose to. How would a firmware help me write heterogeneous bits of c++ code that can run on either cpu or gpu?

IMHO, the question is not that we need code to run on CPUs and GPUs , we do need that, The question is whether the GPU seller has to control both sides. Until I buy a CPU from nvidia I want to keep some kind of independence.

When will we be able to use a future riscv-64 CPU with an nvidia GPU ? we will let the answer to nvidia ?

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

#49

Post by ufo »

amelius wrote: post #20
BoppreH wrote: post #10

Unfortunate name, "cu" it's the most well known slang for "anus" in Brazil (population: 200+ million). "Libcu++" is sure to cause snickering.

"CU" is also an abbreviation of "see you". I don't think it causes much awkwardness, but I could be wrong.

As a Brazilian, I can confirm that we chuckle whenever we see someone use that word :)

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

#50

Post by dahart »

gj_78 wrote: post #48
dahart wrote: post #45

Earlier quoted context omitted.

What do you mean about running in the same memory space? Your operating system doesn’t allow that. Is your concern about using host memory? This open source library doesn’t automatically use host memory, users of the library can write code that uses host memory, if they choose to. How would a firmware help me write heterogeneous bits of c++ code that can run on either cpu or gpu?

IMHO, the question is not that we need code to run on CPUs and GPUs , we do need that, The question is whether the GPU seller has to control both sides. Until I buy a CPU from nvidia I want to keep some kind of independence. When will we be able to use a future riscv-64 CPU with an nvidia GPU ? we will let the answer to nvidia ?

You can use this library to write code that runs on both risc-v and a GPU! You seem to be pretty confused about what this library is. It’s not exerting any control. It’s open source! It’s strictly optional, and it only allows developers to do something they actually want, to write code that will compile for any type of processor that a modern c++ compiler can target.
Post reply on HN