2016Q1: std.blas

Ilya Yaroshenko via Digitalmars-d-announce digitalmars-d-announce at puremagic.com
Sat Dec 26 23:06:09 PST 2015


On Sunday, 27 December 2015 at 05:43:47 UTC, Charles McAnany 
wrote:
> On Saturday, 26 December 2015 at 19:57:19 UTC, Ilya Yaroshenko 
> wrote:
>> Hi,
>>
>> I will write GEMM and GEMV families of BLAS for Phobos.
>>
[...]
>>
>> References:
>> [1] Anatomy of High-Performance Matrix Multiplication: 
>> http://www.cs.utexas.edu/users/pingali/CS378/2008sp/papers/gotoPaper.pdf
>> [2] OpenBLAS  https://github.com/xianyi/OpenBLAS
>>
>> Happy New Year!
>>
>> Ilya
>
> I am absolutely thrilled! I've been using scid 
> (https://github.com/kyllingstad/scid) and cblas 
> (https://github.com/DlangScience/cblas) in a project, and I 
> can't wait to see a smooth integration in the standard library.
>
> Couple questions:
>
> Why will the functions be nothrow? It seems that if you try to 
> take the determinant of a 3x5 matrix, you should get an 
> exception.

Determinant is a part of LAPACK API, but not BLAS API. BTW, D 
scientific code should not throw exceptions if it is possible, 
because it can be integrated with C projects.

> By 'tiny generic code', you mean that DGEMM, SSYMM, CTRMM, etc. 
> all become one function, basically?

No, it is about portability and optimisation. OpenBLAS has huge 
code base it is written in assembler for various platforms. I 
want to make generalise optimisation logic.

> You mention that you'll have GEMM and GEMV in your features, do 
> you think we'll get a more complete slice of BLAS/LAPACK in the 
> future, like GESVD and GEES?

LAPACK can be implemented as standalone package. I hope that I 
will have a time to work on it. Another way is to define new part 
of Phobos with sci.* suffix.

> If it's not in the plan, I'd be happy to work on re-tooling 
> scid and cblas to feel like std.blas. (That is, mimic how you 
> choose to represent a matrix, throw the same type of 
> exceptions, etc. But still use external libraries.)

It will be cool to see scid with Matrix type replaced by 
Slice!(2, double*) / Slice!(2, float*). I will argue to do not 
use any kind of Matrix type, but upcoming Slice 
https://github.com/D-Programming-Language/phobos/pull/3397. 
Slice!(2, double*) is generalisation of matrix type with two 
strides, one for rows and one for columns. std.blas can be 
implemented to support this feature out of the box. Slice!(2, 
double*) do not need to have transposed flag (transpose operator 
only swaps strides and lengths) and fortran_vs_C flag (column 
based vs row based) is deprecated rudiment.

Ilya


More information about the Digitalmars-d-announce mailing list