91–100 of 139 posts
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?
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.
We focused on things that require /different/ implementations in host and device code.
The way you implement std::binary_search is the same in host and device code. Sure, we can stick `__host__ __device__` on it for you, but it's not really high value.
Synchronization primitives? Clocks? They are completely different. In fact, the machinery that we use to implement both the synchronization primitives and clocks has not previously been exposed in CUDA C++.
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
Our end goal is to enable the full C++ Standard Library. The current feature set is just a pit stop on the way there.
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?
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?
Note here that your binaries will continue to run even on future driver versions - and future hardware - that's what PTX is for, as the standard libraries are statically linked in. It's just your object files that aren't compatible, so that you can't mix and match libraries built with different CUDA versions into the same binary.
Unfortunate name, "cu" it's the most well known slang for "anus" in Brazil (population: 200+ million). "Libcu++" is sure to cause snickering.
It gets worse if you try to spell libcu++ without pluses:
libcuxx libcupp (I didn't hate this one but my team disliked it).
We settled on `libcudacxx` as the alphanumeric-only spelling.
“ 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?
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 willing to break ABI. See:
https://cppcast.com/titus-winters-abi/
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p186...
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p213...
Disclosure: I work at Google with several of the people advocating for ABI breaking changes.
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 ?
> Why do they need to run software in the same memory space as my mail reader ?
It is a lot more expensive to build functionality and fix bugs in silicon than it is to do those same things in software.
At NVIDIA, we do as much as we possible can in software. If a problem or bug can be solved in software instead of hardware, we prefer the software solution, because it has much lower cost and shorter lead times.
Solving a problem in hardware takes 2-4 years minimum, massive validation efforts, and has huge physical material costs and limitations. After it's shipped, we can't "patch" the hardware. Solving a problem in software can sometimes be done by one engineer in a single day. If we make a mistake in software, we can easy deploy a fix.
At NVIDIA we have a status for hardware bugs called "Won't Fix, Fix in Next Chip". This means "yes, there's a problem, but the earliest we can fix it is 2-4 years from now, regardless of how serious it is".
Can you imagine if we had to solve all problems that way? Wait 2-4 years?
On its own, our hardware is not a complete product. You would be unable to use it. It has too many bugs, it doesn't have all of the features, etc. The hardware is nothing without the software, and vice versa.
We do not make hardware. We make platforms, which are a combination of hardware and software. We have a tighter coupling between hardware and software than many other processor manufacturers, which is beneficial for us, because it means we can solve problems in software that other vendors would have to solve in hardware.
> I really do not understand why a (very good) hardware provider is willing to create/direct/hint custom software for the users.
Because we sell software. Our hardware wouldn't do anything for you without the software. If we tried to put everything we do in software into hardware, the die would be the size of your laptop and cost a million dollars each.
You wouldn't buy our hardware if we didn't give you the software that was necessary to use it.
> Isn't this exactly what a GPU firmware is expected to do ?
Firmware is a component of software, but usually has constraints that are much more similar to hardware, e.g. long lead times. In some cases the firmware is "burned in" and can't be changed after release, and then it's very much like hardware.
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?
Actually, the basis of our modern GPU compute platform is a technology called Unified Memory, which allows the host and device processor to share access to memory spaces. We think this is the way going forward.
Of course, there's still the process isolation provided by your operating system.
A pathetic attempt to lock developers into their hardware.
Ah-ha, you've caught us! Our plan is to lock you into our hardware by implementing Standard C++.
Once you are all writing code in Standard C++, then you won't be able to run it elsewhere, because Standard C++ only runs on NVIDIA platforms, right?
... What's that? Standard C++ is supported by essentially every platform?
Darnit! Foiled again.