Re: [ublas] new fixed size matrix class

From: Riccardo Rossi (rrossi_at_[hidden])
Date: 2006-08-02 03:13:25

Hi All,
   i admit i am not familiar with how the ublas works at the "low level"

let's consider for example one problem of the type

TinyMatrix<4,3> A;
TinyMatrix<5,3> B;
TinyMatrix<4,5> C;

suppose that the operation we would like to do is
noalias(C) += prod(A,trans(B));

as i understand to obtain maximal performance i should write a
specialization of the product of the type

prod(TinyMatrix<dim1,dim2>::RowOriented,
TinyMatrix<dim1,dim2>::ColOriented)

now my first problem is that i don't know WHERE  to add this specialized
product (in matrix_expressions.hpp??????) and how to make it to work in
practice (i mean the real code for the definition of the function, not
what is done inside). What is done inside should be less complex once i
understand this.

there is in any case another thing i am not sure of:
once in some way i optimized the product operation, am i still paying
any cost for the 

noalias += ...

or i can assume that this is optimized away once i give to the compiler
fixed size matrices? In a ideal word this should completely disappear as
all the operations should be done directly on C...but i guess this is
not the case.

i personally think that the subject is very interesting as it would
bring a sensible performance gain without any code rewriting to the end
user...which is clearly the dream of any user (yessssss ... also my
dream :-D). 

ok, 
        greetings to everyone 

ciao

Riccardo

On Tue, 2006-08-01 at 20:27 +0200, Gunter Winkler wrote:
> emijah_s_at_[hidden] schrieb:
> > Could you please elaborate on the last part? We are using uBlas for a robotics application and the
> > typical size of a matrix tends to be pretty small(around 6x6 typical, 35x35 maximum). So it doesn't 
> > really make sense to use atlas which tends to be effective for large matrices.
> >
> > I'd like to try out what you mentioned to see if we can use it to boost performance a bit.
> >
> >   
> 
> There were a lot of "mul_bench" examples on this list some time ago. The 
> typical problem of ublas is, that it is hard to give the correct 
> (partial) specilization because the expression templates produce very 
> ugly and long types. The first try would be to write a better
> 
> rowmatrix prod(const rowmatrix& a, const colmatrix& b)
> 
> function, but ,as I told, it is hard to chose the correct types for 
> rowmatrix and colmatrix.
> 
> this would be much easier if rowmatrix and colmatrix have a fixed size 
> which is part of the type.
> 
> mfg
> Gunter
> 
> _______________________________________________
> ublas mailing list
> ublas_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/ublas