On Friday, 28 October 2016 at 03:44:05 UTC, Andrei Alexandrescu
wrote:
On 10/27/16 3:59 AM, Ilya Yaroshenko wrote:
Mir GLAS (Generic Linear Algebra Subprograms) has its own
repository [1]
now.
Big news:
1. Mir GLAS does not require D / C++ runtime and can be used
in any
programming language as common C library! See read README [1]
for more
details.
Cool work!
One thing I'd want to understand is how to use Mir GLAS from
within D itself. If it's a straight C interface, there seems to
be a fair amount of friction (we have a D program communicating
with a D library through the uncomfortable confines of a C
interface). Is that the case? Should there be a way to short
circuit the C API and use a more expressive D interface?
(Looking e.g. at Eigen, it's meant to allow people using it
from C++ to take advantage of a C++-specific smooth interface.)
GLAS has 2 APIs: GLAS(ndslise) and BLAS(fortran).
Both APIs has C/C++ and D headers. D headers contains aliases
with unified names like in core.stdc.tgmath. So, extern(C)
interface for GLAS is comfortable and looks like:
gemm(alpha, a, b, beta, c); // calls glas_?gemm
The latest ndslice PR to stable branch solves a problem in case
of const and immutable a and b.
https://github.com/dlang/phobos/pull/4873
GLAS does not have syntax like Eigen, i mean
c = a * b;
This syntax can be a part of another package for scripting like
syntax.
See also Q&A
https://github.com/libmir/mir-glas#why-glas-does-not-have-lazy-evaluation-and-aliasing-like-eigen
6. GLAS is no longer distributed as a generic library. Level 2
and Level
3 generic API will be removed from Mir. There are few reasons
why it is
much better as precompiled library, and no reasons why it
should be
generic. In the same time, generic multidimensional Level 1
routines
will be improved.
I guess I'd like to understand the dynamics better here.
The main reason is compilation time (1 secs+) and template bloat
(50 KB +). OpenBLAS size is more than 20 MB. GLAS is smaller, but
it is not something lightweight like `sort`.
Assume you are buildings a large D projects one-by-one file in
parallel. It can be builded during minutes and its size can be
>100 MB, only because GLAS.
So, having an extern(C) layers is good practice to keep interface
clear and compile time small.
Questions:
1. Would you like GLAS be packed with Phobos?
You have all support from Walter and myself for integrating
GLAS with Phobos. Before that I'd want to make sure we slice
and dice things properly.
Awesome! I am happy to read this)
2. Is it possible to make GLAS a replaceable part of Phobos?
For example
a user may want to use the latest GLAS without waiting a new
compiler
release.
That would be an interesting precedent. We should talk about it
next week. (My knee-jerk reaction is if we're worth our salt we
should release Phobos often enough to obviate the need for
this. But the notion of hot-swapping subcomponents is cool too.)
Some concepts can be found on a slides from my today's talk
https://docs.google.com/presentation/d/1w1cQ8vDluglRIt8Qdnm-sY7kqxoKZxbPEWW6tR3lPpo/edit?usp=sharing
Thanks,
Andrei
Best regards,
Ilya
