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
