Mir GLAS is a C library and passes Natlib's test suite! And questions :-)

[Ilya Yaroshenko via Digitalmars-d]

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