Required DMD changes for Mir and few thoughts about D future

[Nicholas Wilson via Digitalmars-d]

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