From: Jed B. <je...@59...> - 2009-04-09 19:26:03
|
On Thu 2009-04-09 14:03, Kirk, Benjamin (JSC-EG311) wrote: > While we do not currently manage the array ourselves, what I am proposing is > that we make that step, and further to do it in the base class so all the > derived classes can benefit. You still don't have to deal with allocating the memory. You can cache the pointer you get from VecGetArray and Epetra_MultiVector::ExtractView. You won't get the protection that you usually get from VecRestoreArray increasing the state, but you are basically managing that yourself anyway. > Aside from performance, the other major benefit is reducing the number of > external API function calls are required in general. For example, when > putting together the Epetra interface we essentially copied the petsc_vector > source and replaced the petsc api calls with their epetra counterparts. > obviously, the fewer petsc api calls we started with the easier the port > would have been. Yes, although it's not necessarily better to duplicate library functionality than to call their API for it. This can be both a performance issue (their implementation is somehow optimized, perhaps even operating on a copy residing on a GPU) and simple reduction in code duplication. A natural progression is that you manage everything yourself and invert control by implementing PETSc Vec and Epetra_Vector. Being intermediate is more error-prone because you have to know some internals of all implementations. Just something to consider. Jed |