Scientific computing and parallel computing C++23/C++26
iamthewilsonator at hotmail.com
Fri Jan 21 09:45:32 UTC 2022
On Friday, 21 January 2022 at 08:56:22 UTC, Ola Fosheim Grøstad
> On Friday, 21 January 2022 at 03:23:59 UTC, Nicholas Wilson
>> 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.
>> 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
_Just_. I mean it would be doable, but I rather not spend my time
More information about the Digitalmars-d