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

[Nicholas Wilson]

On Thursday, 13 January 2022 at 09:10:48 UTC, Ola Fosheim Grøstad 
wrote:
> Is *dcompute* being actively developed or is it in a "frozen" 
> state? longevity is important for adoption, I think.

not actively per se, but I have been adding features recently...

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

... one of which was compiler support for Vulkan compute shaders 
(no runtime yet Ethan didn't need that, and graphics APIs are 
large, and I'm not sure if there are any good bindings).
Metal is annoyingly different is its kernel signatures, which 
could be done fairly easily, but
* LDC lacks Objective-C support so even if the compiler side of 
Metal support worked the runtime side would not. (N.B. adding 
Objective-C support shouldn't be too difficult. but I don't have 
particular need for it.)
* kernels written for metal would not be compatible with the 
OpenCL and CUDA ones (not that I suppose that would be a 
particular problem if all you care about is Metal.

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

Dcompute essentially sits as a thin layer over both, but 
importantly automates the crap out of the really tedious and 
error prone usage of the APIs. It would be entirely possible to 
create a thicker API agnostic layer over the top of both of them.

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

If there is sufficient interest for it, I might have a go at 
adding Metal compute support to ldc.