Can dcompute even be compiled by stock ldc? If so, you should
change the documents as code.dlang.org suggests otherwise.
PR is open, CI is green, but needs some more work before it will
be accepted.
As I understand it dcompute is a GPU library. Not everyone
will want to or need GPU for doing work with matrices, so even
if/when dcompute can be compiled by stock ldc, I wonder if it
makes sense to prevent Mir being compiled without the
dependency.
DCompute will target OpenCL and CUDA so it can run on the cpu as
well.
OpenCL requires a "non-standard" llvm.
You say it us optional, but then the rest of your message
when read quickly almost suggests it's difficult not to include
it.
As in it will be a setting in mir to support dcompute.
It will be difficult to do the 'compile kernels with ldc and the
rest with dmd'
trick that Ilya suggested for using mir with dmd.
The emphasis is that mir is faster than openblas, which is
great, and natural as a library author to be proud of. I
guess to displace other options in other languages you will
also need to be faster than any other sensible choices,
including Blaze (and I don't know if this is yet the case).
It's a tough sell persuading the Julia and Rust guys to use
your library instead, because people aren't completely
rational about languages, and it's almost an admission of
defeat for them to adopt your solution permanently (more likely
in my view us they try to use your tricks to improve their own
performance) - it would need to be a lot better, is my guess.
Whatever the outcome there is, the emphasis in superior
performance isn't the only one that users will have. If you
want to do matrix work in D, then having a sensible native
solution is much easier - speed is nice, but mostly about ease
of use and reduction in complexity and context switching.
I can't speak for mir, but I intend dcompute to be as user
friendly as CUDA.
Most people are not at the frontier of performance needs, so
this point applies to many potential users, not a minority.
