Re: MTL development road

Hi Michael,

Michael Smolsky schrieb:
> Hi,
>
> MTL looks like a very promising development. I am considering 
> switching my project to MTL.
>
Thank you for the compliment and we are glad about your intentions.
> I would like to know MTL maintainers' opinion about the immediate 
> future of MTL. The first set of questions, that comes to mind is:
>
> * Is there a document, that describes the roadmap for MTL?
>
Currently not.  We have to clarify the funding situation for the project 
at the moment.  Otherwise the roadmap would be pure fiction.
> * I noticed, that MTL currently doesn't do bound checking: my test 
> code, in which I deliberately assigned a value to an out-of-bound 
> element of a dense matrix didn't crash in any way. I find this pretty 
> inconvenient. Having bound checking (when compiled under -DDEBUG) can 
> save a lot of development time. From talking to Java folks, I noticed, 
> that presence such checks in Java libraries, and lack of those in STL 
> implementations was one of the reasons, that drove them away from C++ 
> and towards Java. Is there a plan to add bound checking? A place, such 
> as dense2D.h:rect_offset<..>::elt(..) would be my guess?
>
Are you talking about MTL2 or MTL4?  For the latter this is mostly 
prepared and was later disabled for simple annoying reason.  For STL 
like implementations one needs end-iterators for half-open intervals.  
By nature they are past the end and unfortunately I implemented them by 
&A[i][end_column].  Therefore, the library provokes the exception 
itself.  This annoying detail will be fixed soon.

Thank you for pointing out the importance of it.
> * It's great, that MTL supports some LAPACK/BLAS. With all due respect 
> to optimizations, that are built into MTL, some vendors optimize these 
> libraries to their hardware, and that perhaps can beat sophisticated 
> template unwrapping techniques. Hence my questions:
>
> ** Is there a plan to support sparse BLAS routines? Maybe MTL supports 
> those now, and I just missed it?
>
Is there a sparse BLAS implementation that is worth the effort?  AFAIK 
there is only a prototype in C++ and no hand-tuned implementation.  Even 
if there was I doubt that sparse operations could be implemented much 
faster than in C++.  For dense matrix multiplication the run-time is 
practically independent from memory bandwidth if you use caches well and 
the performance depends on a filigree register choreography that 
compilers these days do quite well but still not with the same 
perfection as hand-tuned code. For sparse matrix operations the run time 
is mainly determined by loading the matrix/matrices and there is not 
much one can do with hardware optimization, eventually some prefetching 
but even this is questionable since there would be not spare bandwidth 
for the it.

I must admit that I only skimmed the sparse BLAS proposal but there are 
several operations supported by MTL that are not part of sparse BLAS, 
e.g., sparse matrix multiplication (which one could use in algebraic 
multigrid methods), sparse dense matrix product (which could be used to 
multiply a sparse matrix simultaneously with multiple vectors).  I 
neither recall that the standard addressed the fundamental question how 
the matrix should be filled.  MTL4 has a very efficient implementation 
for this and the matrix insertion can be done in generic fashion, i.e. 
sparse and dense matrices can be filled in the same way.
> ** It seems, that matrix/vector products are handled by MTL itself, 
> rather than by BLAS. Is this the case? Is there a doc, that describes 
> what functionalities of BLAS/LAPACK are utilized, rather than being 
> implemented within MTL?
>
In MTL2 are 2 files you can just look it up and in MTL4 there is 
currently only matrix multiplication, but this can be done in 
user-transparent manner (a feature I haven't found in another generic 
library yet).
> AMD promises to start selling FireStream boards fairly soon 
> (http://ati.amd.com/products/streamprocessor/specs.html), and those 
> might turn out to be ideal platform for running applications, built on 
> top of MTL. Has anybody tried linking an MTL-based application to 
> ACML, which is AMD's implementation of BLAS/LAPACK?
>
> Regarding the previous questions, it looks like MTL does not use 
> utilize exceptions for reporting BLAS/LAPACK error codes. Is there a 
> plan to wrap LAPACK's INFO variable into exceptions?
>
That's an excellent idea!
> * Is there a reason, why standard matrix-algebraic operations, such as 
> matrix products, addition, etc are not expressed in terms of C++ 
> operators (*, +, etc)?
>
Because it is not trivial to dispatch between all the possible 
multiplication operations.  If one says alpha * A it should return a 
scaled view on a matrix, A * x it should perform a matrix vector 
product, ...

Furthermore, if one has three matrices that approach memory size, one 
don't want to set up another as temporary.  Another reason is 
genericity, mult(A, B, C) allows you to store the temporary results 
directly into C whether it is the same type as A and B or not.  If you 
have an operator A * B you don't know what type C has and if A and B 
have different types what type should have the temporary matrix (that 
might or might not shallow copied to C (but this is already another 
non-trivial problem)).

However, MTL4 supports C= A * B;
- without creating temporaries;
- while supporting arbitrary type combinations; and
- performing dgemm, sgemm, ... if the type combination allows.

Nevertheless there is still a lot to do.  This said, if somebody 
volunteers to extend the interface to BLAS and LAPACK it would be more 
then welcome.  This could also be done as a master thesis, the principle 
is clear and I would be glad to introduce it to the student and if 
desired talk to his/her professor.

Best Regards,

Peter
_______________________________________________
This list is archived at http://www.osl.iu.edu/MailArchives/mtl-devel/