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.
