← Back to team overview

dolfin team mailing list archive

Re: uBlasVector

 


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.
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).
Garth


Follow ups

References