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.pgp>