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. > > 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 > >>> [...] >> >> 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.go ogle.com/ present ation/d/ 1w1cQ8vDlu glRIt8Qdnm- sY7kqxoKZxb PEWW6tR3lPpo/ edit?usp= sharing > >> Thanks, >> >> Andrei > > Best regards, > Ilya 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_?gemmThe 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 meanc = 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- evaluat ion-and- aliasing- like-eigen 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 beSo, having an extern(C) layers is good practice to keep interface clear and compile time small.Awesome! I am happy to read this)Some concepts can be found on a slides from my today's talkBest regards,Ilya