<br><br><div class="gmail_quote">On Thu, Nov 24, 2011 at 6:35 PM, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov">bsmith@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"><br>
On Nov 24, 2011, at 6:30 PM, Dmitry Karpeev wrote:<br>
<br>
> The MPICH paper anticipates O(1B) cores in an exascale machine.<br>
> The number of cores, however, needn't be the number of nodes (with one MPI process per node),<br>
> if each node has O(1000) cores that are programmed using threads or whatever.  If we can limit the number<br>
> of nodes to O(1M) (at the expense of "fattening" the nodes to whatever crazy core counts people envisage in<br>
> the future), then the current PetscLayout may be an acceptable price to pay.<br>
> Otherwise some sort of hierarchical PetscLayout or something entirely different is necessary.<br>
><br>
> In any event, this business of storing explicit ranks/offsets for the ghost indices is sort of antithetical to the current<br>
> PetscLayout-based approach of indices having parallel semantics from the outset.  A lot of conceptual difficulties<br>
> in Sieve and MOAB (and the need for the extra objects such as Overlap and ParallelComm (sic!)) stem from a lack of<br>
> a global address space.  If we are planning to do away with PetscLayout in its current form, I think<br>
> the whole PETSc parallelization model requires rethinking.  That's definitely not an incremental change.<br>
<br>
</div>   Everything is on the table. I could envision a model/implementation of PETSc that has no concept of global numbering and always works with rank,local indexing.<br>
<br>
   Being able to make a user friendly system with any model/implementation, of course, is crucial to whether the proposed system makes any sense.<br></blockquote><div><br></div><div>I would start then by defining the API for PetscLayout (or Overlap, or whatever equivalent object), which defines the local view of the global address space.  That's the only way, it seems to me, to insulate the API exposed to PETSc from these fundamental choices made underneath.</div>

<div><br></div><div>Dmitry.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<span class="HOEnZb"><font color="#888888"><br>
   Barry<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
><br>
> Dmitry.<br>
><br>
> On Thu, Nov 24, 2011 at 6:17 PM, Dmitry Karpeev <<a href="mailto:karpeev@mcs.anl.gov">karpeev@mcs.anl.gov</a>> wrote:<br>
> So then are you planning to re-engineer PetscLayout?<br>
> Or is it acceptable to have a few PetscLayouts, in their current form, lying around?<br>
><br>
> On Thu, Nov 24, 2011 at 6:14 PM, Jed Brown <<a href="mailto:jedbrown@mcs.anl.gov">jedbrown@mcs.anl.gov</a>> wrote:<br>
> On Thu, Nov 24, 2011 at 18:05, Dmitry Karpeev <<a href="mailto:karpeev@mcs.anl.gov">karpeev@mcs.anl.gov</a>> wrote:<br>
> Is O(commSize) storage considered unscalable in this model?<br>
><br>
> 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).<br>


><br>
> The MPICH guys are thinking about this:<br>
><br>
> <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><br>
><br>
><br>
<br>
</div></div></blockquote></div><br>