111–120 of 139 posts
For everyone wondering where are all the data structures and algorithms, vector and several algorithms are implemented by Thrust. https://docs.nvidia.com/cuda/thrust/index.html Seems the big addition of the Libcu++ to Thrust would be synchronization.
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? The C++ Standards Committee has been prioritizing ABI compatibility at the cost of performance for the last decade or so (mostly in the standard library, as opposed the language itself, as I understand it). Some people (especially people from Google) have been arguing that this is the wrong priority, and that C++ should be more willin…
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 wouldn't say it's a gift, though; it's part of what you pay for when you buy one of our products.
Sure, it's not listed as a spec on the box, but users expect that we're going to provide them with a good software stack and support it.
Unfortunate name, "cu" it's the most well known slang for "anus" in Brazil (population: 200+ million). "Libcu++" is sure to cause snickering.
Do chemists have similar problems working with copper, whose chemical symbol is Cu?
Unfortunate name, "cu" it's the most well known slang for "anus" in Brazil (population: 200+ million). "Libcu++" is sure to cause snickering.
These things never seem to matter even in English. How many times have you heard someone say “I don’t like Microsoft”, followed by “that’s what she said”.
Earlier quoted context omitted.
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.
That's basically our current model, I discussed this on Twitter recently.
Earlier quoted context omitted.
Since Unified Memory. UVA, or Unified Virtual Addressing, just ensured that a GPU-private object wouldn't have the same address as a CPU-private object.
You're right, sorry. Mixing up terms.
My first week at NVIDIA:
Me, to very senior engineer: something something UVM.
Very senior engineer: What's UVM?
Me: Unified Virtual Memory.
Very senior engineer: Don't call it that, call it Unified Memory, no abbreviation. TLAs are evil.
Me: What's TLA?
Very senior engineer: Three letter acronym.
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,…
> 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…
There appears a llvm libcxx bundled in as part of the repo. What's the purpose of that libcxx?
“ 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?