<meta http-equiv="Content-Type" content="text/html; charset=utf-8"><div dir="ltr">Depending on the size of your data, you could pipeline a series of MPI_Igather calls and process all of the data associated with the partial buffer.  Of course, this will change the layout of the buffer at the root unless you do something interesting with datatypes (e.g. struct with offset).  This may or may not matter, if you are going to process it anyways.<div><br></div><div>In general, I think you may be able to do just fine with rolling your own.  It's a myth that using higher-level functionality in MPI is _always_ better.</div><div><br></div><div>Jeff</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 21, 2015 at 7:03 PM, Balaji, Pavan <span dir="ltr"><<a href="mailto:balaji@anl.gov" target="_blank">balaji@anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Eric,<br>
<br>
The concept of partial completion of collectives did come up in the Forum, but the Forum decided that it was rather unnatural to define Iallgather/Igather that way.  So we decided to standardize it the way it is.<br>
<br>
However, there is a separate proposal for streaming collectives, which is more along the lines of what you are thinking of.  That's obviously not in MPI-3, but might be considered for a future MPI.  You might want to join the collectives working group and voice your opinion over there.<br>
<br>
With respect to writing your own igather implementation, as long as your implementation is logarithmic, it won't be too bad.  However, a native implementation inside MPI would almost certainly do better because: (1) it can take advantage of platform-specific features to improve performance, and (2) if the platform doesn't give anything special, it'll anyway do exactly what you are doing above MPI.<br>
<br>
So, apart from any performance bugs that the implementation might have, using MPI Igather would be the recommended mechanism for the best performance.<br>
<br>
  -- Pavan<br>
<div><div class="h5"><br>
<br>
<br>
<br>
<br>
On 10/21/15, 2:45 PM, "Eric Chamberland" <<a href="mailto:Eric.Chamberland@giref.ulaval.ca">Eric.Chamberland@giref.ulaval.ca</a>> wrote:<br>
<br>
>Hi,<br>
><br>
>A long time ago (in 2002) we programmed here a non-blocking MPI_Igather<br>
>with equivalent calls to MPI_Isend/MPI_Irecv (see the 2 attached files).<br>
><br>
>A very convenient advantage of this version, is that I can do some work<br>
>on the root process as soon as it start receiving data...  Then, it wait<br>
>for the next communication to terminate and process the received data.<br>
><br>
>Now, I am looking at MPI_Igather (and all non-blocking collective MPI<br>
>calls), and I am somewhat surprised (or ignorant) that I cannot have the<br>
>root rank receive some data, then process it, then wait until the next<br>
>"MPI_irecv" terminate...<br>
><br>
>In other words, a MPI_Igather generate only 1 MPI_Request but I would<br>
>like to have either "p" (with p = size of communicator) MPI_Request<br>
>generated or be able to call "p" times MPI_WaitAny with the same<br>
>MPI_Request...  Am I normal? :)<br>
><br>
>So my 3 questions are:<br>
><br>
>#1- Is there a way to use MPI_Igather with MPI_WaitAny (or something<br>
>else?) to process data as it is received?<br>
><br>
>#2- Big question: will our implementation with MPI_Isend/MPI_Irecv scale<br>
>to a large number of processes?  What are the possible drawbacks of<br>
>doing it like we did?<br>
><br>
>#3- Why should I replace our implementation by the native MPI_Igather?<br>
><br>
>Thanks!<br>
><br>
>Eric<br>
</div></div>_______________________________________________<br>
discuss mailing list     <a href="mailto:discuss@mpich.org">discuss@mpich.org</a><br>
To manage subscription options or unsubscribe:<br>
<a href="https://lists.mpich.org/mailman/listinfo/discuss" rel="noreferrer" target="_blank">https://lists.mpich.org/mailman/listinfo/discuss</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Jeff Hammond<br><a href="mailto:jeff.science@gmail.com" target="_blank">jeff.science@gmail.com</a><br><a href="http://jeffhammond.github.io/" target="_blank">http://jeffhammond.github.io/</a></div>
</div>