<div class="gmail_quote">On Wed, May 30, 2012 at 10:29 AM, Timothy Stitt <span dir="ltr"><<a href="mailto:Timothy.Stitt.9@nd.edu" target="_blank">Timothy.Stitt.9@nd.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi all,<br>
<br>
I am currently trying to improve the scaling of a CFD code on some Cray machines at NERSC (I believe Cray systems leverage mpich2 for their MPI communications, hence the posting to this list) and I am running into some scalability issues with the MPI_WIN_CREATE() routine.<br>

<br>
To cut a long story short, the CFD code requires each process to receive values from some neighborhood processes. Unfortunately, each process doesn't know who its neighbors should be in advance. </blockquote><div><br>
</div><div>How often do the neighbors change? By what mechanism?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">To overcome this we exploit the one-sided MPI_PUT() routine to communicate data from neighbors directly.<br>

<br>
Recent profiling at 256, 512 and 1024 processes shows that the MPI_WIN_CREATE routine is starting to dominate the walltime and reduce our scalability quite rapidly. For instance the %walltime for MPI_WIN_CREATE over various process sizes increases as follows:<br>

<br>
256 cores - 4.0%<br>
512 cores - 9.8%<br>
1024 cores - 24.3%<br></blockquote><div><br></div><div>The current implementation of MPI_Win_create uses an Allgather which is synchronizing and relatively expensive.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
I was wondering if anyone in the MPICH2 community had any advice on how one can improve the performance of MPI_WIN_CREATE? Or maybe someone has a better strategy for communicating the data that bypasses the (poorly scaling?) MPI_WIN_CREATE routine.<br>

<br>
Thanks in advance for any help you can provide.<br>
<br>
Regards,<br>
<br>
Tim.<br>
_______________________________________________<br>
mpich-discuss mailing list     <a href="mailto:mpich-discuss@mcs.anl.gov">mpich-discuss@mcs.anl.gov</a><br>
To manage subscription options or unsubscribe:<br>
<a href="https://lists.mcs.anl.gov/mailman/listinfo/mpich-discuss" target="_blank">https://lists.mcs.anl.gov/mailman/listinfo/mpich-discuss</a><br>
</blockquote></div><br>