VecGhost and state

Jed Brown jed at 59A2.org
Thu Apr 30 10:42:48 CDT 2009


Matthew Knepley wrote:
> But any time someone creates a new mechanism, they have to respect this.
> This is why when the local vector mechanism was introduced, it broke this
> immediately.

That is always the case with caching.  The presence of CPU caches and
disk caches dramatically complicates things.  Of course, I'm happy that
I don't have 250 cycle latency on every load and that compilation is 100
times faster.

The benefit of caching in PETSc is less dramatic, and it's probably not
too hard to do it without any impact on performance, at the expense of
explicitly passing norms around in a few places (ugly and obfuscates the
algorithm).  I think this would be worse than the existing caching
mechanism.

> Programming should not be about what will do the job, but also what
> is transparent and robust. This is neither.

The issue is caching and aliasing.  With most PETSc objects, there is no
aliasing.  VecGhost is elegant and compact, but has aliasing.  Aliasing
complicates the semantics of caching, but it's not really that bad,
although it would benefit from better documentation.


I pushed synchronization with maximum, 4e0af22ff310.

Jed

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20090430/7fa66867/attachment.sig>


More information about the petsc-dev mailing list