Anders Logg wrote: > On Thu, Apr 10, 2008 at 04:12:51PM +0100, Garth N. Wells wrote: >> >> Anders Logg wrote: >>> 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. >>> >> I liked being able to access the extensive uBLAS functionality directly >> without overhead, but that's getting too hard now with the new la design >> so I'm happy to follow the PETScVector design. So let's do it and also >> follow the same design for for uBlasMatrix. > > Good. It will require some work to go through the ODE solver classes > and the uBlas Krylov solver classes to make sure they don't > deteriorate performance-wise with the change. >
If they first get hold of the pointer to the underlying uBLAS object and work with that, performance shouldn't be an issue. Garth >>> 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? >>> >> We don't have much of that in uBlasVector because uBlasVector is tied to >> a particular uBLAS data type, but we will probably still need it in >> uBlasMatrix because various underlying matrices can be used (dense, >> sparse, row major, column major, etc). > > ok. > _______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
