<div class="gmail_quote">On Mon, Dec 26, 2011 at 23:37, 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=":2t4">Window creation will always need to be synchronizing, at least to gather size and base address parameters.<br></div></blockquote><div><br></div><div>Hmm, what about limiting scope, e.g. if I knew a priori which process groups I would use as arguments to MPI_Win_post() and MPI_Win_start()? Is there anything useful you could do if I only knew the process group for MPI_Win_start()?</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":2t4">
<br>
"Re-seating" a window with a different memory is essentially creating a new window. What are you trying to accomplish?<br></div></blockquote></div><br><div>It's cumbersome for a user to always arrange to reuse some special memory, probably with different types at different times. I have a choice of (a) memcpy into existing window memory and (b) wrap a window around the user's memory. For short messages, the memcpy version will be faster.</div>
<div><br></div><div>Sometimes I'm accessing parts of a buffer that is much larger than the send/receive volume (specified by composite MPI_Datatypes). The memcpy costs proportional to the size of the whole buffer rather than to the communication volume. I can pack, but this involves one more transaction during setup.</div>
<div><br></div><div>Note that a single communication object of mine might have multiple in-flight operations at a given time, each using different windows, so I would be keeping a cache of windows.</div>