Scientific computing and parallel computing C++23/C++26

[Ola Fosheim Grøstad]

On Thursday, 13 January 2022 at 07:23:40 UTC, Bruce Carneal wrote:
> I disagree.  D/dcompute can be used as a better general purpose 
> GPU kernel language now (superior meta programming, sane nested 
> functions, ...).

Is *dcompute* being actively developed or is it in a "frozen" 
state? longevity is important for adoption, I think.

> There *are* improvements to be made but, by my lights, dcompute 
> is already better than CUDA in many ways.  If we improve 
> usability, make dcompute accessible to "mere mortals", make it 
> a "no big deal" choice instead of a "here be dragons" choice, 
> we'd really have something.

Maybe it would be possible to do something with a more limited 
scope, but more low level? Like something targeting Metal and 
Vulkan directly? Something like this might be possible to do well 
if D would change the focus and build a high level IR.

I think one of Bryce's main points is that there is more long 
term stability in C++ than in the other APIs for parallel 
computing, so for long term development it would be better to 
express parallel code in terms of a C++ standard library 
construct than other compute-APIs.

That argument makes sense for me, I don't want to deal with CUDA 
or OpenCL as dependencies. I'd rather have something sit directly 
on top of the lower level APIs.

> By contrast, I just don't see the C++ crowd getting to 
> sanity/simplicity any time soon... not unless ideas from the 
> circle compiler or similar make their way to mainstream.

It does look a bit complex, but what I find promising for C++ is 
that Nvidia is pushing their hardware by creating backends for 
C++ parallel libraries that targets multiple GPUs. That in turn 
might push Apple to do the same for Metal and so on.

If C++20 had what Bryce presented then I would've considered 
using it for signal processing. Right now it would make more 
sense to target Metal/Vulkan directly, but that is time 
consuming, so I probably won't.