2 ms·

> If you care about portable GPU code, unfortunately, NVIDIA is the only vendor that actually delivers. Absolutely false. First, GPU code is inherently unporta

> If you care about portable GPU code, unfortunately, NVIDIA is the only vendor that actually delivers. Absolutely false. First, GPU code is inherently unportable in terms of performance. Switch to another vendor's GPU, or to another microarchitecture, and you may need to rewrite your entire kernel. But even other than that: NVIDIA promotes its own proprietary and mostly-closed-source ecosystem, named CUDA, and has actively hampered the adoption and development of OpenCL, which was supposed to be the open standard. Not that OpenCL was not "betrayed" by others, but still. > They voted GPU support into the C++ 2017 and Fortran 2018 ISO standards There is no GPU support in the C++ standard. If you mean something like `std::par` as an execution strategy for standard library algorithm, that's rather limited in scope and not really GPU-specific. > While NVIDIA implemented this YEARS ago Again not quite sure what you mean. Are you talking about how you can't write GPU kernels in C++17? Or about `std::par` implementations for the standard libraries? > You can take your standard conforming C++ code _today_, not a single line of CUDA, OpenMP, OpenACC, etc. and the nvidia compiler compiles it and runs it on GPUs and multi-core CPUs. This doesn't make sense, and it's also not true. On a GPU, you would not use a lot of the standard library to get things done; that would either be exceedingly slow or just not work. Also, some language features (like exceptions) don't work on GPUs, and for good reason; hence anything in the standard library which relies on exceptions for error handling also doesn't work as-is - which is perfectly ok. > You can also take your normal Python NumPy code and run it on NVIDIA GPUs "as is" without changes. This is the only part of what you've written which is mostly-true (and I haven't fully verified even this since I don't do Python work).

volta83 5y ago
TL;DR: the parent doesn't know what they are talking about and for some reason is burnt over OpenCL which is a horrible ""standard"" (Khronos extension over C and C++, not actual C++ support, in the C++ ISO standard proper). Maybe the reason people like HIP and OneAPI is because they are not aware that you can program GPUs using ISO C++ and ISO Fortran because... Intel and AMD don't support those? > Absolutely false. [...] If you mean something like `std::par` [...] not really GPU-specific std::par is the ISO C++ standard feature for parallel programming, this includes multi-core CPUs, SIMD, GPUs, FPGAs, etc. NVIDIA compilers run std::par on both CPUs and GPUs. I've been using it for over a year, and so have a lot of people I work with. You claim that this is false, but this is demonstrably true, and there are many peer-reviewed papers of people using this with NVIDIA compilers already. The claim that this model of GPU programming is not portable, is false as well, since Intel and AMD claimed that this is portable to their GPUs when they added it to the C++ standard in 2017. The claim that this does not deliver performance portability is also false, since we have verified performance portability across 3 NVIDIA GPU architectures, and using Kokkos, which exposes a similar programming model, also to Intel and AMD architectures.
- jeeceebees 5y ago
  How does the performance between GPU programs written with std::par compare to those written in CUDA? Do you happen to know of any online resources that show a comparison of the kernel code and performance of the two frameworks on common tasks?
  - volta83 5y ago
    This paper ported a CFD application, which had a tuned CUDA implementation, to std::par: https://arxiv.org/pdf/2010.11751.pdf https://arxiv.org/pdf/2010.11751.pdf . In Table 3, first and last columns shows the performance of CUDA and std::par in % of theoretical peak. The rows show results for different GPU architectures. On V100, CUDA achieves 62% theoretical peak and std::par 58%. The amount of developer effort required to achieve over 50% theoretical peak with std::par makes it a no brainer IMO. If there is one kernel where you need more performance, you can always implement that kernel in CUDA, but for 99% of the kernels in your program your time might be better spent elsewhere.

volta83 5y ago

TL;DR: the parent doesn't know what they are talking about and for some reason is burnt over OpenCL which is a horrible ""standard"" (Khronos extension over C and C++, not actual C++ support, in the C++ ISO standard proper). Maybe the reason people like HIP and OneAPI is because they are not aware that you can program GPUs using ISO C++ and ISO Fortran because... Intel and AMD don't support those? > Absolutely false. [...] If you mean something like `std::par` [...] not really GPU-specific std::par is the ISO C++ standard feature for parallel programming, this includes multi-core CPUs, SIMD, GPUs, FPGAs, etc. NVIDIA compilers run std::par on both CPUs and GPUs. I've been using it for over a year, and so have a lot of people I work with. You claim that this is false, but this is demonstrably true, and there are many peer-reviewed papers of people using this with NVIDIA compilers already. The claim that this model of GPU programming is not portable, is false as well, since Intel and AMD claimed that this is portable to their GPUs when they added it to the C++ standard in 2017. The claim that this does not deliver performance portability is also false, since we have verified performance portability across 3 NVIDIA GPU architectures, and using Kokkos, which exposes a similar programming model, also to Intel and AMD architectures.

jeeceebees 5y ago
How does the performance between GPU programs written with std::par compare to those written in CUDA? Do you happen to know of any online resources that show a comparison of the kernel code and performance of the two frameworks on common tasks?
- volta83 5y ago
  This paper ported a CFD application, which had a tuned CUDA implementation, to std::par: https://arxiv.org/pdf/2010.11751.pdf https://arxiv.org/pdf/2010.11751.pdf . In Table 3, first and last columns shows the performance of CUDA and std::par in % of theoretical peak. The rows show results for different GPU architectures. On V100, CUDA achieves 62% theoretical peak and std::par 58%. The amount of developer effort required to achieve over 50% theoretical peak with std::par makes it a no brainer IMO. If there is one kernel where you need more performance, you can always implement that kernel in CUDA, but for 99% of the kernels in your program your time might be better spent elsewhere.