tor, 10.04.2008 kl. 12.48 +0100, skrev Garth N. Wells: > > 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 >
What I thought, but I have checked is that with the different sequence of inheritance, the operators might not be re-implemented because the operators from ublas would be used and not the operators of GenericVector. But I have not checked and I have to go now. Kent _______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
