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.

2. Netlib's BLAS test suite are part of CI testing.

3. D and C/C++ headers and examples are provided. D headers are available as dub package [2].

4. Both `std.experimental.ndslice` and `mir.ndslice` are supported.

5. GLAS headers supports all D compilers with DMD FE > 2.070.

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.

Questions:

1. Would you like GLAS be packed with Phobos?

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.

[1] https://github.com/libmir/mir-glas
[2] http://code.dlang.org/packages/mir-glas

Best regards,
Ilya

On Wednesday, 26 October 2016 at 19:59:21 UTC, Ilya Yaroshenko wrote:
> Mir GLAS (Generic Linear Algebra Subprograms) has its own repository [1] now.


Keep up the good work!

On the read-me page, I have a few suggestions for improvements.

The installation section could use some improvement. Most important is that you just have two sections for mir-cpuid and mir-glas sort of out of nowhere. Maybe mention them in the first installation section. Also, that section says "The last one should be used." might be revised to "It is recommended to use ldmd2 with mir-glas." There's a missing the in "Recent LDC packages come with [the] dub package manager." You might also note that .a files are .lib files on Windows.

In the Q&A section, you might mention that it doesn't use D's GC. Also, that first answer should read "GLAS has a generic...". The same issue shows up in #5 of the second question. And the answer to question 3 should be something like "GLAS is a lower level library than Eigen. For example, GLAS can be an Eigen BLAS back-end in the future"

On Wednesday, 26 October 2016 at 20:23:01 UTC, jmh530 wrote:
> On Wednesday, 26 October 2016 at 19:59:21 UTC, Ilya Yaroshenko wrote:


Thanks!

Please wait around a year after the last major breaking api change.
Its the kind of library that will be severely limited by Phobos requirements. After all by your own post, the API still needs a lot of work done to it and this way it can mature up nicely.

On 10/26/2016 12:59 PM, Ilya Yaroshenko wrote:
> Mir GLAS (Generic Linear Algebra Subprograms)

Ilya is giving a talk in about 5 hours on D runtime infrastructure which Mir GLAS is a proof of concept of:

  http://forum.dlang.org/thread/nu8qq8$2i1a$1@digitalmars.com

Ali

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

> 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.

> 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.

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


Thanks,

Andrei

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

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

On Friday, 28 October 2016 at 16:14:56 UTC, Sameer Pradhan 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
>

For GPUs there is dcompute (also on libmir's github) on the way, although it'll be probably another month (exams, joy!) before the compiler stuff gets fully merged into LDC and we can start on an API that forwards to OpenCL/CUDA, and doesn't suck to use.

If you have any experience with either OpenCL or CUDA we'd love to have your input.

On Saturday, 29 October 2016 at 01:43:03 UTC, Nicholas Wilson wrote:
>
> If you have any experience with either OpenCL or CUDA we'd love to have your input.

Have experience with both, more CUDA than OpenCL though. Feel free to contact me.