← Back to team overview

dolfin team mailing list archive

Re: uBlasVector

 



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.





References