<div class="gmail_quote">On Tue, Dec 27, 2011 at 21:27, Pavan Balaji <span dir="ltr"><<a href="mailto:balaji@mcs.anl.gov">balaji@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 id=":nh">Hmm... On second thought, it might be possible to make it not synchronize by passing an info argument (though it's not implemented yet). In this case, the base address and other information can be queried on-demand when the next PUT/GET/ACCUMULATE operation occurs.</div>
</blockquote><div><br></div><div>Or in the next Win_post/Win_start sequence?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":nh"> When memory registration is involved, this will be even messier. So I guess it's theoretically possible, though there's no plan to do it at present. Also, from a portability perspective, you can never assume that there will not be synchronization (other MPI implementations might not respect this info argument).<br>
</div></blockquote><div><br></div><div>I don't care about the semantics of synchronization (it always occurs inside a collective interface anyway), it's just a question of performance. If the operation always involves an MPI_Allgather() then it can't be used in performance-sensitive places on a large machine (because the cost of a scalar MPI_Allreduce() is already many times more than "halo exchange").</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":nh">
<br>
In MPI-3, there's an option for dynamically attaching memory to windows. That's probably the best option for you. We are working on implementing it for our next major release (1.5).</div></blockquote><div><br></div>
<div>I'd be happy to test it out in some of our use scenarios.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":nh"><div class="im"></div>
The part I don't understand here is what benefit does wrapping an existing window object around new memory give you? Why not create a new window object around your new memory?</div></blockquote></div><br><div>Nothing in terms of semantics, but if it is less expensive to wrap new memory than to create a new window, then we can do that.</div>