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

51–60 of 139 posts

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

#51

Post by mlvljr »

XorNot wrote: post #40
formerly_proven wrote: post #39

Earlier quoted context omitted.

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.

Needs 15 more years of hype cycles, that's why only :)

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

#53

Post by pantalaimon »

XorNot wrote: post #40
formerly_proven wrote: post #39

Earlier quoted context omitted.

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.

The solution for this is now Docker, Flatpack, Snap, …

Just ship the whole environment and only rely on the stable kernel API.

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

#54

Post by [deleted] »

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…

[deleted]

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

#55

Post by surajrmal »

pantalaimon wrote: post #53
XorNot wrote: post #40

Earlier quoted context omitted.

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.

The solution for this is now Docker, Flatpack, Snap, … Just ship the whole environment and only rely on the stable kernel API.

This is very wasteful. On servers in the cloud that may be a reasonable approach, but there are still devices that are memory, storage, and/or network constrained enough where it's not. It's still necessary to have relatively stable interfaces such that most things can share the same version of a dependency and their still exists the ability to deduplicate the dependencies between different programs. I do agree that the current OS approaches to handle this are not great and there is room for new models, but docker containers are not a holistic solution.

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

#56

Post by formerly_proven »

surajrmal wrote: post #55
pantalaimon wrote: post #53

Earlier quoted context omitted.

The solution for this is now Docker, Flatpack, Snap, … Just ship the whole environment and only rely on the stable kernel API.

This is very wasteful. On servers in the cloud that may be a reasonable approach, but there are still devices that are memory, storage, and/or network constrained enough where it's not. It's still necessary to have relatively stable interfaces such that most things can share the same version of a dependency and their still exists the ability to deduplicate the dependencies between different programs. I do agree that…

The Windows Component Store (aka Side-by-Side aka WinSxS) is sort of a content-addressed store for DLLs and the like, except the content-addressing isn't facilitated by a literal cryptographic hash over the contents, but instead by the logical identity of the component (name+version but more). And, it doesn't fetch anything automatically. Writes to certain paths are just intercepted and redirected into it, while storing an association somewhere else that the app that did that (or was installed doing that) wants that particular component (or at least, that's how I think that works).

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

#57

Post by jlebar »

This is super-cool.

For those of us who can't adopt it right away, note that you can compile your cuda code with `--expt-relaxed-constexpr` and call any constexpr function from device code. That includes all the constexpr functions in the standard library!

This gets you quite a bit, but not e.g. std::atomic, which is one of the big things in here.

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

#58

Post by patrec »

XorNot wrote: post #40
formerly_proven wrote: post #39

Earlier quoted context omitted.

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.

Nix basically already does this, apart from the decentralised distributed cache (there is a centralised one and you can easily set up your own, too). All references, including to dynamically linked libraries are via unique, content addressable hash -- where "content" currently still happens to be content of the build recipe and all dependencies and sources, recursively, not the built artefact. There is work on referencing artefacts by the binary output hash though, because that obviously has better security properties when you want to have a non-centralized cache; the main problem is that a lot of software still has no reproducible build.

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

#59

Post by roel_v »

happyweasel wrote: post #6
roel_v wrote: post #3

Earlier quoted context omitted.

Yeah, really tiny... At first I thought 'wow this is a game changer', but then I looked at your link and thought 'what's the point?'. Can someone explain what real problems you can solve with just the headers in the link above?

It runs on the GPU?

What runs on the gpu?

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

#60

Post by TillE »

roel_v wrote: post #3
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

Yeah, really tiny... At first I thought 'wow this is a game changer', but then I looked at your link and thought 'what's the point?'. Can someone explain what real problems you can solve with just the headers in the link above?

I would have expected the header, but instead...synchronization primitives? std::chrono? I'm completely baffled about how that would be useful, but that's probably because I know very little about CUDA.
Post reply on HN