<div>The MPICH paper anticipates O(1B) cores in an exascale machine.</div>The number of cores, however, needn't be the number of nodes (with one MPI process per node),<div>if each node has O(1000) cores that are programmed using threads or whatever.  If we can limit the number </div>

<div>of nodes to O(1M) (at the expense of "fattening" the nodes to whatever crazy core counts people envisage in </div><div>the future), then the current PetscLayout may be an acceptable price to pay.</div><div>

Otherwise some sort of hierarchical PetscLayout or something entirely different is necessary.</div><div><br></div><div>In any event, this business of storing explicit ranks/offsets for the ghost indices is sort of antithetical to the current</div>

<div>PetscLayout-based approach of indices having parallel semantics from the outset.  A lot of conceptual difficulties </div><div>in Sieve and MOAB (and the need for the extra objects such as Overlap and ParallelComm (sic!)) stem from a lack of </div>

<div>a global address space.  If we are planning to do away with PetscLayout in its current form, I think</div><div>the whole PETSc parallelization model requires rethinking.  That's definitely not an incremental change.</div>

<div><br></div><div>Dmitry.</div><div><br><div class="gmail_quote">On Thu, Nov 24, 2011 at 6:17 PM, Dmitry Karpeev <span dir="ltr"><<a href="mailto:karpeev@mcs.anl.gov">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;">

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 class="HOEnZb"><div class="h5"><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" target="_blank">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><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>
</div></div></blockquote></div><br></div>