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

121–130 of 139 posts

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

#121

Post by blelbach »

justicezyx wrote: post #119
blelbach wrote: post #101

Earlier quoted context omitted.

> apparently only a small bit of the library is actually implemented. Yep. It's an incremental project. But stay tuned. > I'm somewhat suspicious of the presumption of us using NVIDIA's version of the standard library for our host-side work. Today, when using libcu++ with NVCC, it's opt-in and doesn't interfere with your host standard library. I get your concern, but a lot of the restrictions of today's GPU toolchain…

How this library works? There appears a llvm libcxx bundled in as part of the repo. What's the purpose of that libcxx?

That involves a few diagrams, but essentially, we have two layers:

- the libcu++ layer, which has some of our extensions and implementations specific to our platform. - the libc++ layer, which is a modified upstream libc++.

A header in the libcu++ layer defines the libc++ internal macros in a certain way, and then includes the applicable libc++ header.

This is the current architecture, but we're moving away towards a more integrated approach where almost everything is in the libc++ layer.

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

#122

Post by quotemstr »

retrac wrote: post #80
quotemstr wrote: post #65

Earlier quoted context omitted.

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.

The C++ standard library is a bit different from a platform API. The C++ standard library is a template system designed to conform exactly to your particular program. It should always be statically linked. I see zero advantage to dynamic linking of libc++. A platform API, on the other hand, is designed to stable, safe, and flexible, not fast --- because programs in general shouldn't be calling into the system so much. The performance costs we accept in a platform API (e.g., user to kernel privilege transition) would be totally unacceptable as part of an STL data structures implementation.

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

#123

Post by jameshilliard »

blelbach wrote: post #106
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.…

> To be clear, I don't think nvidia-paid developers should be able to write C++ Code for a nvidia-sold GPU. I'm not sure what you're saying here? You think another company or organization should write all the software for our hardware? I don't think you understand the semiconductor industry. Our business model relies on hardware and software engineers working closely together, as I've described in other replies. We w…

I get the impression nvidia puts out a lot of their hardware supporting software themselves because they are hostile to open source community collaboration in general. This could be because nvidia is a big fan of vendor lock in.

> Also, what motivation does this other organization or company have to create software for our hardware?

Typically an organization like this would be a user of nvidia hardware, that's like asking what motivation Microsoft has for writing software/toolchains for Intel hardware. Maybe this attitude is why nvidia is notorious for having a terrible open source software experience for Linux graphics.

> Our hardware is useless without our software.

It's not(https://nouveau.freedesktop.org/wiki/) but nvidia is considered one of the worst hardware vendors when it comes to having proper open source driver/toolchain support. The situation used to be even worse but it's still not great now.

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

#124

Post by blelbach »

shaklee3 wrote: post #27
lars wrote: post #2

It really is a tiny subset of the C++ standard library, but I'm happy to see they're continuing to expand it: https://nvidia.github.io/libcudacxx/api.html

Nvidia has had many members on the c++ standards committee for a while.

I'm not sure how making a large contribution to the C++ Standard is a problem?

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

#125

Post by blelbach »

jameshilliard wrote: post #123
blelbach wrote: post #106

Earlier quoted context omitted.

> To be clear, I don't think nvidia-paid developers should be able to write C++ Code for a nvidia-sold GPU. I'm not sure what you're saying here? You think another company or organization should write all the software for our hardware? I don't think you understand the semiconductor industry. Our business model relies on hardware and software engineers working closely together, as I've described in other replies. We w…

I get the impression nvidia puts out a lot of their hardware supporting software themselves because they are hostile to open source community collaboration in general. This could be because nvidia is a big fan of vendor lock in. > Also, what motivation does this other organization or company have to create software for our hardware? Typically an organization like this would be a user of nvidia hardware, that's like a…

> I get the impression nvidia puts out a lot of their hardware supporting software themselves because they are hostile to open source community collaboration in general. This could be because nvidia is a big fan of vendor lock in.

It's not hostility, it's about agility. More so than other hardware vendors, we rely on really tight integration between hardware and software.

In some situations, we find a hardware bug that would require another manufacturer to do a "respin" (e.g. restart the manufacturing process with a new, fixed design). Because we have tight control over the software stack, we can workaround that bug. It's faster for us to do this when we have full control. Also, sometimes these bugs have security implications, etc.

That said, we've been moving in the direction of open source for a long time.

> It's not(https://nouveau.freedesktop.org/wiki/)

The other fellow was suggesting we should write no software at all. Nouveau's struggles is an excellent example of how difficult it is to write software for hardware without the engagement and interaction of the manufacturer of that hardware.

TL;DR you're talking about whether our software should open source versus closed source; the other fellow was suggesting we shouldn't have software at all.

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

#126

Post by gumby »

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, or was back in the day, a standard Unix utility (call up) — connect to another machine via modem.

It doesn’t appear to be in Ubuntu any more but still in openbsd, netbsd, and macos!

You can’t win win these namespace collisions: I have friends whose names are obscenities in other languages I speak.

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

#127

Post by shaklee3 »

blelbach wrote: post #124
shaklee3 wrote: post #27

Earlier quoted context omitted.

Nvidia has had many members on the c++ standards committee for a while.

I'm not sure how making a large contribution to the C++ Standard is a problem?

Sorry, that was not my intent. I was pointing out that Nvidia has made significant contributions already to the c++ standard, so this is not the first thing they've done.

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

#128

Post by higerordermap »

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.

Do they use some kind of ABI versioning?

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

#129

Post by dahart »

jameshilliard wrote: post #123
blelbach wrote: post #106

Earlier quoted context omitted.

> To be clear, I don't think nvidia-paid developers should be able to write C++ Code for a nvidia-sold GPU. I'm not sure what you're saying here? You think another company or organization should write all the software for our hardware? I don't think you understand the semiconductor industry. Our business model relies on hardware and software engineers working closely together, as I've described in other replies. We w…

I get the impression nvidia puts out a lot of their hardware supporting software themselves because they are hostile to open source community collaboration in general. This could be because nvidia is a big fan of vendor lock in. > Also, what motivation does this other organization or company have to create software for our hardware? Typically an organization like this would be a user of nvidia hardware, that's like a…

Aren’t we commenting in response to the posting of a new open source library that helps support a standard tool chain?

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

#130

Post by pjmlp »

einpoklum wrote: post #102
pjmlp wrote: post #79

Earlier quoted context omitted.

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.

> 1. Ever heard of Nights and Visual Studio plugins? Those are apples and oranges... also, you forget cuda-gdb. > OpenCL 1.2 got renamed as OpenCL 3.0. C++ bindings were dropped Well, yes, but also no. They were made optional, and transitioned to some other C++-cum-OpenCL initiative: https://github.com/KhronosGroup/Khronosdotorg/blob/master/ap... I'm not exactly sure how this differs and what's usable in practice tho…

While SYSCL might stand a chance against CUDA, thanks to it being backend agnostic and a compiler neutral standard, C++ for OpenCL is a clang specific project which remains to be seen if it ever will get any adoption.

> For C++ kernel development, the OpenCL Working Group has transitioned from the original OpenCL C++ kernel language, defined in OpenCL 2.2, to the ‘C++ for OpenCL’ community, open-source project supported by Clang. C++ for OpenCL provides compatibility with OpenCL C, enables developers to use most C++17 features in OpenCL kernels, and is compatible with any OpenCL 2.X or OpenCL 3.0 implementation that supports SPIR-V™ ingestion.

https://www.khronos.org/news/press/khronos-group-releases-op...

Post reply on HN