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