MTL: MTL development road

[Michael Smolsky-2]

Hi,

MTL looks like a very promising development. I am considering switching my project to MTL.

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?

* 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?

* 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?

** 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?

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?

* Is there a reason, why standard matrix-algebraic operations, such as matrix products, addition, etc are not expressed in terms of C++ operators (*, +, etc)?

Thank you for programming and supporting something, that looks like a very useful library.

Regards,

Michael.

--

Over 2 Million Holiday Gift Ideas - Take a Look!
mail.com Shopping

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

[Peter Gottschling]

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/

[Rene van Paassen-2]

On Mon, 2007-12-03 at 10:53 +0100, Peter Gottschling wrote:
> Hi Michael,
>
> Michael Smolsky schrieb:
> > Hi,
> >
> > MTL looks like a very promising development. I am considering
> > switching my project to MTL.

Snip

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

We use MTL in real-time applications. There it is extremely important to
avoid temporaries, since allocation / freeing of memory will quickly
lead to unpredictable timing. A "fancier" matrix library like newmat is
not compatible with real-time software.

--
M.M. (René) van Paassen    | ______o____/_|     M.M.vanPaassen@...
Associate Professor       <[___\_\_-----<      t/f: [phone]/86480
Aerospace Engineering      |  o'              http://www.cs.lr.tudelft.nl
Delft University of Technology           Kluijverweg 1, NL-2629 HS  Delft
###########################################

This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange.
For more information, connect to http://www.f-secure.com/

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