So then are you planning to re-engineer PetscLayout?<div>Or is it acceptable to have a few PetscLayouts, in their current form, lying around?</div><div><br><div class="gmail_quote">On Thu, Nov 24, 2011 at 6:14 PM, Jed Brown <span dir="ltr"><<a href="mailto:jedbrown@mcs.anl.gov">jedbrown@mcs.anl.gov</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im"><div class="gmail_quote">On Thu, Nov 24, 2011 at 18:05, Dmitry Karpeev <span dir="ltr"><<a href="mailto:karpeev@mcs.anl.gov" target="_blank">karpeev@mcs.anl.gov</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Is O(commSize) storage considered unscalable in this model?</blockquote></div><br></div><div>I would like to avoid it where possible. If we have million-way parallelism at the network level (e.g. one million MPI processes), then we have to justify the memory usage. One 64-bit integer per process is 8MB. If that is needed once for the entire application, it is probably not an issue, but if it's needed by every object, then it could add up to a substantial amount (considering the low-memory estimates).</div>


<div><br></div><div>The MPICH guys are thinking about this:</div><div><br></div><div><a href="http://www.mcs.anl.gov/~goodell/pdfs/mpi-mem-final.pdf" target="_blank">http://www.mcs.anl.gov/~goodell/pdfs/mpi-mem-final.pdf</a></div>


</blockquote></div><br></div>