4 ms·

NVIDIA, Intel and AMD sit on the ISO C++ and ISO Fortran standard committees. They voted GPU support into the C++ 2017 and Fortran 2018 ISO standards. While NVI

NVIDIA, Intel and AMD sit on the ISO C++ and ISO Fortran standard committees. They voted GPU support into the C++ 2017 and Fortran 2018 ISO standards. While NVIDIA implemented this YEARS ago, almost 5 years after these ISO standards were voted in, Intel and AMD have not even announced a plan for implementing GPU support for ISO standard languages on their GPUs. Instead, Intel and AMD strategy is pushing applications to "rewrite CUDA with HIP/OneAPI", which are not real standards and are no more portable than CUDA. The people claiming that they are "open", probably also think that OpenACC is an open standard, even though it mostly only runs on NVIDIA GPUs. If you care about portable GPU code, unfortunately, NVIDIA is the only vendor that actually delivers. 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. You can also take your normal Python NumPy code and run it on NVIDIA GPUs "as is" without changes. It doesn't get any more portable than that. I don't understand how there are so many people in these threads that apparently care about portability happy about AMD and Intel rewriting open source applications in their proprietary vendor-specific technologies, instead of angry about them pushing their proprietary technologies, instead of implementing GPU support for ISO standard languages, just like NVIDIA does.

toolz 5y ago
just playing devils advocate here, but if only one vendor is conforming to these standards - could it be that the standards are heavily biased towards their implementation?
- volta83 5y ago
  Intel and AMD voted to add GPU support to the C++ and Fortran ISO standards. Are you implying that they did a bad job and added the wrong GPU support to ISO C++? Or maybe that Intel and AMD don't care about C++, and either added GPU support to it that they could not implement, or don't care about adding C++ support to their GPUs? Playing devil's advocate here, no matter how you want to frame this, it just does not look good for Intel and AMD.
- jjoonathan 5y ago
  If it was just that I'd expect catch-up to happen within a couple years and a generation of cards, but the problem has persisted for many years and many generations of cards. I tend to suspect that NVidia just invests far more in software than their competition. Hopefully now that AMD has money that will change.
nspattak 5y ago
On top of that, the only supported cards are radeon rx 6x00, as if the 10 miners who own these cards around the world even care about writing GPGPU code :)
- account42 5y ago
  Can we please let go of that meme - GPUs prices are currently high due to the chip shortage and mining demand, yes, but definitely not too high for professional users to afford them. It sucks if you want an entertainment device and are on a budget but let's not pretend that these cards are unavailable entirely. The RX 6000 series will have been out for a year tomorrow. I was able to grab one within a week after the release just by checking online stores a couple of times each day so while they did keep going out of stock, there was new stock coming in too.
einpoklum 5y ago
> 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.

toolz 5y ago

just playing devils advocate here, but if only one vendor is conforming to these standards - could it be that the standards are heavily biased towards their implementation?

volta83 5y ago
Intel and AMD voted to add GPU support to the C++ and Fortran ISO standards. Are you implying that they did a bad job and added the wrong GPU support to ISO C++? Or maybe that Intel and AMD don't care about C++, and either added GPU support to it that they could not implement, or don't care about adding C++ support to their GPUs? Playing devil's advocate here, no matter how you want to frame this, it just does not look good for Intel and AMD.
jjoonathan 5y ago
If it was just that I'd expect catch-up to happen within a couple years and a generation of cards, but the problem has persisted for many years and many generations of cards. I tend to suspect that NVidia just invests far more in software than their competition. Hopefully now that AMD has money that will change.

nspattak 5y ago

On top of that, the only supported cards are radeon rx 6x00, as if the 10 miners who own these cards around the world even care about writing GPGPU code :)

account42 5y ago
Can we please let go of that meme - GPUs prices are currently high due to the chip shortage and mining demand, yes, but definitely not too high for professional users to afford them. It sucks if you want an entertainment device and are on a budget but let's not pretend that these cards are unavailable entirely. The RX 6000 series will have been out for a year tomorrow. I was able to grab one within a week after the release just by checking online stores a couple of times each day so while they did keep going out of stock, there was new stock coming in too.

einpoklum 5y ago

> 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.