Required DMD changes for Mir and few thoughts about D future

[Laeeth Isharc via Digitalmars-d]

On Tuesday, 27 September 2016 at 01:55:17 UTC, Nicholas Wilson 
wrote:
> On Monday, 26 September 2016 at 22:34:59 UTC, Andrei 
> Alexandrescu wrote:
>> On 9/26/16 10:11 PM, Ilya Yaroshenko wrote:
>>> A precompiled library based on top of Mir GLAS can be used 
>>> with DMD.
>>
>> That would work out as long as interaction is seamless. Please 
>> advise. Overall: I think Ilya's work can make a real 
>> difference for D, and we can't afford it to not work with the 
>> reference implementation. -- Andrei
>
> Mir will be (optionally) integrated with dcompute (once it is 
> ready)
> and dcompute CANNOT be compiled at all by dmd, although I 
> suppose
> you could use dmd for rapid development cycle, but you would 
> have to
> make dmd only figure out the .mangleof of the kernel (as the 
> .mangleof
> is required for the library-side API bashing magic) and not try 
> to do any
> semantic analysis or compilation, as it would fail horribly.

Can dcompute even be compiled by stock ldc?  If so, you should 
change the documents as code.dlang.org suggests otherwise.

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. 
   You say it us optional,  but then the rest of your message when 
read quickly almost suggests it's difficult not to include it.

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.   Most 
people are not at the frontier of performance needs,  so this 
point applies to many potential users, not a minority.