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 > _______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
