[petsc-dev] [petsc-maint #87175] Resizing of the nonzero pattern

[Jed Brown]

On Sat, Sep 17, 2011 at 01:07, Shri <abhyshr at mcs.anl.gov> wrote:

> > That space is allocated, but the matrix has been compacted so only the
> > first
> > 832 slots in the array are considered. The other part gets pushed out
> > to
> > slow memory and only takes up space, not bandwidth. This is often not
> > a big
> > deal.
>
> What is the reason for retaining this 'extra' memory? Is it to avoid
> fetching memory again
> if the user wants to insert more values in the matrix via any future
> assembly calls?


Reallocating, copying, and freeing may increase the peak memory usage of the
application, thus limiting the problem size. In practice, on most systems
with virtual memory, the extra memory could be released using realloc()
without needing a copy. On an offset-mapped system (e.g. BG/P), this could
cause fairly serious fragmentation problems, so the operating system might
prefer to copy.

I don't know why PETSc has never adopted the use of realloc(). I suspect
that portability is a problem, but could improve performance a bit for some
dynamically growing data structures, and in some common cases like matrix
preallocation, allow some space to be recovered.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20110917/0dac7b1d/attachment.html>