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

[Nicholas Wilson]

On Friday, 21 January 2022 at 08:56:22 UTC, Ola Fosheim Grøstad 
wrote:
> On Friday, 21 January 2022 at 03:23:59 UTC, Nicholas Wilson 
> wrote:
>> There are two major advantages for compile time features, for 
>> the host and for the device (e.g. GPU).
>
> Are these resolved at compile time (before the executable is 
> installed on the computer) or are they resolved at runtime?

Before. But with SPIR-V there is an additional 
compilation/optimisation step where it is converted into whatever 
format the hardware uses, also you could set specialisation 
constants here if I ever get around to supporting those. I think 
it probably also happens with PTX (which is an assembly like 
format) to whatever the binary format is.

> I guess there might be instances where you might want to 
> consider to change the entire data layout to fit the hardware, 
> but then you to some extent outside of what most D programmers 
> would be willing to do.

Indeed.

>> You want it to be transparent, not invisible.
>
> The goal is to make it look like a regular C++ library, no 
> extra syntax.

There is an important difference between it looking like regular 
C++ (i.e. function calls not <<<>>>) and the compiler doing 
auto-GPU-isation. I'm not sure which one you're referring to 
here. I'm all for the former, that's what Dcompute does, the 
latter falls too far into the sufficiently advanced compiler and 
would have to necessarily determine what to send to the GPU and 
when, which could seriously impact performance.

> Just write the whole runtime in Objective-C++. Why would it be 
> ugly?

_Just_. I mean it would be doable, but I rather not spend my time 
doing that.