Hacker News Reader

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

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.

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?

This paper ported a CFD application, which had a tuned CUDA implementation, to std::par: 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.

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?

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.

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.

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 :)

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.