Re:CUDA vs. ROCm: A Case Study
by throwaway81523 on Tuesday December 19, 2023 @10:59PM
(#38705293)
Don't know about the libs but CUDA itself is a C++ dialect targeted at a family of quirky array processors (GPU's). That takes some dev work by compiler hackers but doesn't seem amazing. Am I missing something? It's of course still easy to mess up such a project by not bringing enough clue, and AMD might have done that with ROCm. Is that what happened, or is it something different?
[ Parent
| on HN ]
CUDA is more than a C++ dialect, which is a big thing people keep missing with all those "CUDA replacements".
Until CUDA 3.0, it was similar to OpenCL, a C dialect, however afterwards it became a C, C++ dialect, with common infrastructure PTX.
PGI targeted PTX, with their C, C++, and very relevant, Fortran compilers for HPC.
PGI was acquired by NVidia, and became the main set of CUDA compilers.
Given PTX, many other languages started targeting CUDA as well, Java, .NET, Haskell, Julia, at very least.
NVidia is now invested into a Python JIT for CUDA as well.
So yeah, while C++20 is the main language in CUDA, there is also a whole ecosystem of programming languages, that the "CUDA replacements" keep ignoring.
Re:CUDA vs. ROCm: A Case Study
by throwaway81523 on Wednesday December 20, 2023 @04:38AM
(#38706879)
In these CUDA vs ROCm comparisons I think they mostly compare the C++ dialects. And it's not even particularly the language implementation where ROCm is weak, but rather, the whole tool chain. Am I mistaken?
Which is why it will never be a CUDA replacement, for most C++ users maybe, for the whole ecosystem definitly not.
Re:CUDA vs. ROCm: A Case Study
by throwaway81523 on Wednesday December 20, 2023 @02:25PM
(#38712523)
Well the C++ segment is important and from what I gather, ROCm is failing at that. AMD would be a lot better off if the C++ part worked, even if the other parts don't.