www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Mir GLAS is a C library and passes Natlib's test suite! And questions

reply Ilya Yaroshenko <ilyayaroshenko gmail.com> writes:
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
Oct 26 2016
next sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
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 

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"
Oct 26 2016
parent Ilya Yaroshenko <ilyayaroshenko gmail.com> writes:
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!
Oct 26 2016
prev sibling next sibling parent rikki cattermole <rikki cattermole.co.nz> writes:
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.
Oct 26 2016
prev sibling next sibling parent =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
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
Oct 27 2016
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Oct 27 2016
parent reply Ilya Yaroshenko <ilyayaroshenko gmail.com> writes:
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
Oct 27 2016
parent reply Sameer Pradhan <pradhan cemantix.org> writes:
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
Oct 28 2016
parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
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.
Oct 28 2016
parent reply Guillaume Piolat <contact lolnotspam.g4mesfrommars.fr> writes:
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.
Oct 29 2016
parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Saturday, 29 October 2016 at 10:21:02 UTC, Guillaume Piolat 
wrote:

 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.


Great! I'll let you know when the compiler stuff is merged, 
probably in mir's public gitter.
Oct 29 2016
parent deXtoRious <dextorious gmail.com> writes:
On Saturday, 29 October 2016 at 11:25:17 UTC, Nicholas Wilson 
wrote:

 On Saturday, 29 October 2016 at 10:21:02 UTC, Guillaume Piolat 
 wrote:

 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.


 Great! I'll let you know when the compiler stuff is merged, 
 probably in mir's public gitter.


I have experience with both CUDA and OpenCL. As soon as the 
compiler stuff is in, I'd be happy to port some of my standard 
microbenchmarks (mostly computational fluid dynamics stuff) and 
see how it stacks up in both performance/ease of use and get you 
some feedback.

I'm following the git repo and occasionally checking these 
forums, but feel free to contact me via e-mail or any other 
medium.
Nov 02 2016