[petsc-users] cached values

Patrick Sanan patrick.sanan at gmail.com
Sun Apr 26 19:29:23 CDT 2015


This might be more basic than what you're trying to find out, but the
reason that "assembly" is required in the first place (even for serial
code) is that that during the process of defining the matrix, it's useful
to be able to insert values anywhere in the matrix. I'm not sure what PETSc
does precisely with digging into the source, but a common way to approach
things is to maintain a data structure which looks like a C array of
(row,col,val) entries (if you have ever used the Eigen library, they call
these "Triples" and you can work with C++ STL vector of them). This is the
COO ("COOrdinate list") format for storing a sparse matrix. Typically one
uses a more highly-compressed format, like CSR ("Compressed Row Storage") ,
which does not allow of efficient insertion and deletion of entries. This
tension motivates requiring the user to explicitly assemble the matrix.

On Sun, Apr 26, 2015 at 7:13 PM, Jed Brown <jed at jedbrown.org> wrote:

> Justin Chang <jychang48 at gmail.com> writes:
>
> > Jed,
> >
> > Thank you for the response. But where exactly are the values from
> > MatSetValues() stored or located? That is, are they in main memory, or
> are
> > they occupying space in the L1/L2/L3 cache?
>
> Caches are not programmable in that way.  PETSc incrementally allocates
> a data structure that holds the "stashed" values.  It depends on the
> details of your application and the hardware cache semantics whether a
> particular access will trigger a cache miss or not.  You can find out
> using hardware performance counters, but it's not likely to be worth
> your time unless you just want to learn those tools.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20150426/83eb009e/attachment.html>


More information about the petsc-users mailing list