3 ms·
" Even then, while access to GPGPUs is now pretty much universal, GPGPU programming still feels like it is in the stone ages. Despite being a thing for over 10
by jerf 4y ago
" Even then, while access to GPGPUs is now pretty much universal, GPGPU programming still feels like it is in the stone ages. Despite being a thing for over 10 years."
I'd be interested in reading an article from someone who has been doing it for 10 years as to why that is the case. I have theories but nowhere near enough direct experience to evaluate.
(My hypothesis is that the extreme parallelism makes it so very tiny mistakes have catastrophic performance impact by introducing accidental serialism, and as a result, it is very difficult to create an "easy to use" framework that doesn't abstract too much away and make it trivially easy to introduce even a tiny such error and crash performance. We actually make this mistake all the time in conventional CPU code, it just generally just costs you small integer multiples of performance instead of large integer multiples of performance.)
- cogman10 4y agoMy hypothesis is more cynical. We have 4 major GPGPU manufactures (Apple, Intel, AMD, nVidia) and none of them want to make creating an open standard easy. There is no reason why nVidia should support OpenCL the same way that AMD does, they want people to write CUDA. There's no reason for Apple to support OpenAAC like Intel does, they want people to write Metal... etc. These 4 companies are trying to push everyone into their proprietary ecosystem or into an open ecosystem where they have a large say. I had hoped that SPIR-V would be a good inroad to start fixing some of these problems, but alas, it seems like Apple and nVidia aren't big fans. It's early still, though, so maybe that changes?
- pjmlp 4y agoAMD and Intel don't care enough about OpenCL to actually provide the same tooling and libraries that CUDA does. OpenCL 2.x was a failure, hence why OpenCL 3.0 is basically 1.2 with everything else from 2.x marked as optional.