<div class="gmail_quote">On Fri, Nov 25, 2011 at 09:38, Mark F. Adams <span dir="ltr"><<a href="mailto:mark.adams@columbia.edu">mark.adams@columbia.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div>My point is that at some point the rubber has to hit the road and you need two side information.  You can then set up pointers for some fast one-sided stuff, and that is fine but you seem to agree that this is trivial.  Its not clear to me that your model is not simply removing some (redundant) data from the user space, while it is probably in the MPI library.</div>
</blockquote><div><br></div><div>Whether this information is ever visible inside the MPI stack is dependent on the network. In general, it is never stored at once within the stack and the operations may be done without involving the CPU on the owning process (some network cards can do these operations directly on memory). If the MPI stack wanted to, it could log these operations, but I really meant it when I said it's not needed.</div>
<div><br></div><div>Even with some funky implementation that built full two-sided information internally, I think the simpler user-level abstraction would be worthwhile.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br><blockquote type="cite"><div class="gmail_quote"><div>This information is communicated to the ghosters of that point (again without knowing how many there are), </div></div></blockquote><div><br></div>
</div><div>But you knew how many there were, and chose to forget it, and the MPI layer must know how many there are so it knows when its done communicating.  I'm not sure how you insure correctness with your model.</div>
</blockquote><div><br></div><div>I never knew. We can ask: what is required to add another level of ghosting? With my model, the owner never needs to be informed that some procs are ghosting another level, nor be aware what those ghosted nodes are. It may place some data in an array for the "pointwise broadcast" of connectivity, but it doesn't need semantic knowledge that that information will used to increase the ghosting. Similarly, any process can stop ghosting a point without informing the owner in any way.</div>
<div><br></div><div>Completion comes through MPI_Win_fence() which is collective, but not globally synchronizing (so neighbor communication must have completed, but it's not like an MPI_Barrier or MPI_Allreduce. </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im"><blockquote type="cite"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div> I can assume that my fine grid was well partitioned, and to keep the process local assume the fine grid was partitioned with a space filling curve, or something, such that when I aggregate processors (eg, (0-3), (4-7) ... if I reduced the number of active processor by 4) I still have decent data locality.  Eventually I would like a local algorithm to improve load balance at this point, but that is more than you might want to start with.</div>

</blockquote><div><br></div><div>If you have a local graph partitioner that can tell you what to move for better load balance, then I think I can move it efficiently and without redundant storage or specification.</div></div>
</blockquote><div><br></div></div>How do you load balance with a local partitioner?</blockquote></div><br><div>You said you wanted a local algorithm to improve load balance. I took that to mean that you would redistribute within a subcommunicator and, with simple communication, inform the rest of the processes of the new partition. I think this will work fine.</div>
<div><br></div><div>What did you have in mind?</div>