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

[Sameer Pradhan via Digitalmars-d]

On Friday, 28 October 2016 at 06:31:19 UTC, Ilya Yaroshenko wrote:
> On Friday, 28 October 2016 at 03:44:05 UTC, Andrei Alexandrescu 
> wrote:
>> On 10/27/16 3:59 AM, Ilya Yaroshenko wrote:
>>> [...]

I must plead ignorance on the finer interface details, but from 
what I am reading this seems like an amazing development. I am so 
happy that that D has a solid base for GPU work.

The post from a few weeks back with performance details compared 
to BLAS and others was quite impressive. details I was just 
telling Steve at the Boston meetup yesterday that libmir and now 
MirGLAS has really made me jump up and down to start using D 
seriously for some language processing work I have been hoping to 
use it for. I have been an observer and reader for several years 
now, but haven't taken the leap. Yet. Hopefully soon...

--
Sameer



>>> [...]
>>
>> 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
>
>>> [...]
>>
>> 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.
>
>>> [...]
>>
>> 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)
>
>>> [...]
>>
>> 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