Re: [ublas] new fixed size matrix class

From: Dave Steffen (dgsteffen_at_[hidden])
Date: 2006-08-09 11:29:20

Hajime SAITO writes:
 > 
 > Thank you for your replies. Sorry for the late response.
 > 
 > We are working on a simulator that we plan to release as open source. I 
 > have looked at Tvmet and also MTL. I tried benchmarking with BTL which 
 > is something that was part of the OpenCascade project and found that 
 > indeed tvmet was faster. However I was thinking that if boost::ublas was 
 > the larger effort so perhaps we could contribute back to it and prevent 
 > all these open source projects from diverging and creating packages that 
 > are slightly different from each other. I was also looking at using the 
 > boost graph library and other components so I chose uBlas.
 > 
 > I think there are others who feel the same way about performance for 
 > small matrices. I am willing to try things out with the code we 
 > currently have to make comparisons.
 > 
 > I find the generation of specializations appealing if there are too many 
 > combinations to consider. However(like the questions Ricardo Rossi has 
 > posted) I have yet to find the location to which I can add the 
 > specializations.
 > 
 > Dave Steffen wrote:
[...]
 > >
 > >  Tvmet is also worth a look, if you're looking around; explicitly
 > >  build for small problems ("tiny vector matrix expression template",
 > >  or some such) and it's extremely fast, according to my profiling.

 In fact, I can report that according to my results, tvmet is just
 about the fastest thing out there, and... alas... ublas is just about
 the slowest.

 Now, that may not be entirely fair; I didn't spend much time figuring
 out what things to do to make ublas fast.  On the other hand, I spent
 more time figuring out how to make ublas fast, and how to just make
 it work period, than I did to make tvmet do anything.

Compare my tvmet test code:

     #include <tvmet/Matrix.h>
     ...
      tvmet::Matrix<double,N,N> a;
      tvmet::Matrix<double,N,N> b;
      tvmet::Matrix<double,N,N> c;
     ... 

     a += b;
     c = a * b;

with:

#include <boost/numeric/ublas/vector.hpp>
#include <boost/numeric/ublas/matrix.hpp>
#include "ublas_cholesky.hpp"
#include <boost/numeric/ublas/matrix_expression.hpp>
// Gymnastics to simulate typedefs for the ^%#$^%#'in boost types.
namespace UB
{
    using namespace boost::numeric::ublas;

    template <int N>  struct Type
    {
        typedef matrix<double, row_major, bounded_array<double, N*N> > matrix;
    };
}
 ...
    typename UB::Type<N>::matrix a(N,N), b(N,N), c(N,N);
 ...

    a += b;
    noalias(c) = prod(a,d);

Aside from having to look up the spelling of 'prod' and find the
existence of 'noalias', the type of that matrix is nasty.  Granted,
given that uBLAS provides a 'complete' set of matrix types, there are
going to be some nasty template things floating around... 

The point is, that AFICT the += operation above took uBLAS ~300
instructions, for N=2, and took tvmet 12; and the matrix product took uBLAS ~
1000 and tvmet ~40.

Granted, tvmet doesn't have 
  - support for dynamic-sized containers
  - support for different matrix storage types (symmatric, hermitian, 
    lower triangular, etc)
  - Higher-level linear algebra (Cholesky decomp, etc).
It's a much smaller, lighter weight library.  But I found it to be
much easier, and much much much faster, than uBLAS.

It would be great if you could speed uBlas up!

----------------------------------------------------------------------
Dave Steffen, Ph.D.      
Software Engineer IV              Disobey this command!
Numerica Corporation
ph [phone] x27    
fax [phone]                   - Douglas Hofstadter
dgsteffen_at_[hidden]
___________________
Numerica Disclaimer:
This message and any attachments are intended only for the individual
or entity to which the message is addressed.  It is proprietary and
may contain privileged information.  If you are neither the intended
recipient nor the agent responsible for delivering the message to the
intended recipient, you are hereby notified that any review,
retransmission, dissemination, or taking of any action in reliance
upon, the information in this communication is strictly prohibited,
and may be unlawful.  If you feel you have received this communication
in error, please notify us immediately by returning this Email to the
sender and deleting it from your computer.