Re: [boost] uBLAS formal review

From: Matthias Troyer (troyer_at_[hidden])
Date: 2002-07-01 12:33:29

Dear Boosters,

I would like to add my comments to the ublas review.

First of all I found the ublas authors very quick in responding
to questions, eager to explain things and receptive to new ideas.
This is an important consideration for such a complex package.

Next, I strongly support a Boost matrix library, having seen the
need for one in my own research all too often.

As far as ublas is concerned I want to raise the following issues,
that apply to what I expect of a Boost matrix library and where
ublas might need to be improved, either before acceptance or
shortly thereafter:

1.) I would prefer to be able to write a matrix-vector product
     as M*v, without the need to use the prod(M,v) function.
     Similarly I would like to be able to write a vector inner product
     as something like x.transpose()*y or transpose(x)*y

2.) If a Boost matrix library, such as ublas, wants to find
     acceptance in the scientific community at which it is aimed,
     performance at BLAS/Atlas level are a MUST. A 5-10%
     penalty might be acceptable, but factors of 2 or larger
     are a no-go. After all we run our codes on multi-million $
     machines, and a factor of two in speed can go into thousands
     of dollars (fortunately not real money for most of us, but
     one should keep the actual cost of ones' research in mind)

3.) Related to that, we need optimal performance of an expression
     like A*B*v, as was discussed by others. All reasonable expressions
     a user might write should be near-optimal in performance for dense
     matrices.

4.) Finally, there is one other essential issue: extensibility of the
     library. I need to be able to interface my own data structures for
     vectors and matrices. Often we need to take a data structure provided
     by another library as matrix or vector. If it is not possible to use
     them directly, it should be easy to write wrappers, adn this should
     be documented well and examples given.

5.) Interfaces to LAPACK calls at least for dense matrices.

If a Boost matrix library fulfills criteria 2-5 (criterion 1 is
nice-to-have but a must) I can envision using it myself and endorsing
it for other large-scale scientific code developments that are
currently being started and where I am partially involved.
If performance and extensibilty are not guaranteed, ublas would
remain just-another matrix library and would not be able
to be establish itself as a standard.

My sincere wish is that the Boost matrix library will be efficient
and flexible enough to become the long-missing standard and I urge
the ublas authors to seriously think about the performance issues
that were already raised by others. I would love to switch to
a Boost matrix library as soon as possible, would use it
in all my research code, and also in my lectures and student
projects.

I also hope that the ublas authors can turn ublas into such
an efficient library and would then vote yes for inclusion into
boost. If however, the performance problems cannot be solved
at this time I would rather wait another year for a better
solution than to get an inefficient Boost matrix library now.

Matthias