← Back to team overview

dolfin team mailing list archive

Re: uBlasVector

 

On Thu, Apr 10, 2008 at 12:48:16PM +0100, Garth N. Wells wrote:
> 
> 
> 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.

Sounds good to me. Martin suggested exactly this just this morning,
but I said I think Garth won't like it.

Anyway, it makes perfect sense to do this. Just as for PETSc, we can
have mat() and vec(). It should also remove the need for all the scary
template programming we have now in uBlasFoo?

-- 
Anders


> > 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
> > 
> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/mailman/listinfo/dolfin-dev


Follow ups

References