dolfin team mailing list archive

["Garth N. Wells" <gnw20@xxxxxxxxx>]

Kent-Andre Mardal wrote:
> The new functions are the functions that have been added to
> GenericVector, right ? 
>
> I guess you refer e.g. to the fact that axpy have been re-implemented in
> terms of a for loop instead of using the template expression y += a*x ?

Yes.

> The reason for this re-implementation is the operators implmented in
> GenericVector. These operators mess up the operators previously
> implemented by ublas_vector. 
>
> What is the performance penalty ? 

uBLAS is better at performing various operations than we are. The 
current implementation involves element access and the extra function 
calls do have an impact for the size matrices we work with. We did 
extensive testing some time ago, and the general conclusion was that 
direct access to uBLAS functions is important for smallish vectors.

An unattractive feature of uBlasVector is that we have a mix-mash of 
functionality from the uBlasVector interface and the ublas_vector 
interface (including member functions with the same name). Should 
uBlasVector simply own a ublas_vector and uBlasVector can return the 
pointer to the ublas_object is a user needs it? This would mirror the 
PETScVector design. Then we would know for sure where functions are 
coming from.

> Does it help to change: 
>
>   class uBlasVector : public GenericVector,
>                       public Variable,
>                       public ublas_vector
>
>
> to 
>
>   class uBlasVector : public ublas_vector,
>                       public Variable,
>                       public GenericVector
>
>
> ?

I don't think so because uBlasVector re-implements some uBLAS 
functionality (+=, -=, etc). I can't figure out how to wrap these 
operators from uBLAS because they are very complicated.

Garth

> Kent
>
> tor, 10.04.2008 kl. 11.59 +0100, skrev Garth N. Wells:
> > ons have been introduced to uBlasVector. Are these 
> > functions essential? The problem that I'm facing is that we use uBlas 
> > objects a lot to manipulate relatively small vectors and matrices, so 
> > performance is a consideration. Previously we accessed uBLAS
> > functions 
> > directly. This issue is compounded by the fact that I haven't been
> > able 
> > to figure out how to elegantly wrap number of the functions because 
> > uBLAS uses expression templates.
> >
> > If we need the extra functions, we'll probably try to work directly
> > with 
> > uBLAS (by creating a ublas_vector). ublas_vector is base class for 
> > uBlasVector, so can we cast it easily to a uBlasVect