[mpich-discuss] How to use non-blocking send/receive without calling MPI_Wait

[Jeff Hammond]

MPI_Wait does not guarantee that the data sent with MPI_Isend is received.
It merely means you can reuse the send buffer.  If you want to be sure it
has been received, use MPI_Issend (synchronous send).

I assume that you don't actually care if the data has been received, in
which case you should not use synchronous send, since it may be slower than
regular send, due to additional synchronization.

Jeff

On Fri, Apr 3, 2015 at 2:46 PM, Lei Shi <lshi at ku.edu> wrote:

> Pavan,
>
> In my case, I don't care the data is correct or not. I know it sounds
> crazy at first time, but there are some numerical schemes designed for this
> situation.
>
> I think according to Jeff's post
> http://blogs.cisco.com/performance/dont-leak-mpi_requests. If we don't
> call MPI_Wait or test, the request object will not be released even the
> data transfer completes.
>
> I will test your suggestion to call  MPI_Request_free to release
> it manually.
>
> BTW, attached is my test result,
> 1. The orange one uses MPI_ISend/MPI_IRecv with MPI_Wait to make sure the
> data has been received successfully.  The WTime is linear with iterations,
> which is correct.
>
> 2. The blue one uses MPI_ISend and MPI_IRecv without calling MPI_Wait.
> There are some jumps in WTime. Does it due to some resource leaking? I will
> try to call MPI_Request_free to solve those jumps.
>
> 3. The green one uses MPI_IBsend and MPI_IRecv (should I use MPI_Recv with
> MPI_IBsend) without calling MPI_Wait. It is even slower than the case 1
> with MPI_Wait.
>
>
>
>
> On Fri, Apr 3, 2015 at 1:29 PM, Balaji, Pavan <balaji at anl.gov> wrote:
>
>>
>> No, the request object will get released fine when the data transfer
>> completes.  It is a correct program.  What I meant is that, since the
>> application never knows when the request completes, the user application
>> cannot use the data in any meaningful way, IMO.
>>
>>   -- Pavan
>>
>> > On Apr 3, 2015, at 12:13 PM, Lei Shi <lshi at ku.edu> wrote:
>> >
>> > Pavan,
>> >
>> > Thanks. You mean since I don't call MPI_Wait at all, the request object
>> does not get a chance to be released by the MPI library? Right? I will give
>> it a try. Thanks again!
>> >
>> >
>> > On Fri, Apr 3, 2015 at 10:12 AM, Balaji, Pavan <balaji at anl.gov> wrote:
>> >
>> > You can free the request with MPI_Request_free if you don't want to
>> wait on it.  I have no idea how you'll write a correct program without
>> waiting for receive completions at least, though.
>> >
>> >   -- Pavan
>> >
>> > > On Apr 2, 2015, at 11:44 PM, Lei Shi <lshi at ku.edu> wrote:
>> > >
>> > > Hi Junchao,
>> > >
>> > > Thanks for your reply. For my case, I don't want to check the data
>> have been received or not. So I don't want to call MPI_Test or any function
>> to verify it. But my problem is like if I ignore calling the MPI_Wait, just
>> call Isend/Irev, my program freezes for several sec and then continues to
>> run. My guess is probably I messed up the MPI library internal buffer by
>> doing this.
>> > >
>> > >
>> > > On Thu, Apr 2, 2015 at 7:25 PM, Junchao Zhang <jczhang at mcs.anl.gov>
>> wrote:
>> > > Does MPI_Test fit your needs?
>> > >
>> > > --Junchao Zhang
>> > >
>> > > On Thu, Apr 2, 2015 at 7:16 PM, Lei Shi <lshi at ku.edu> wrote:
>> > > I want to use non-blocking send/rev MPI_Isend/MPI_Irev to do
>> communication. But in my case, I don't really care what kind of data I get
>> or it is ready to use or not. So I don't want to waste my time to do any
>> synchronization  by calling MPI_Wait or etc API.
>> > >
>> > > But when I avoid calling MPI_Wait, my program is freezed several secs
>> after running some iterations (after multiple MPI_Isend/Irev callings),
>> then continues. It takes even more time than the case with MPI_Wait.  So my
>> question is how to do a "true" non-blocking communication without waiting
>> for the data ready or not. Thanks.
>> > >
>> > >
>> > > _______________________________________________
>> > > discuss mailing list     discuss at mpich.org
>> > > To manage subscription options or unsubscribe:
>> > > https://lists.mpich.org/mailman/listinfo/discuss
>> > >
>> > >
>> > > _______________________________________________
>> > > discuss mailing list     discuss at mpich.org
>> > > To manage subscription options or unsubscribe:
>> > > https://lists.mpich.org/mailman/listinfo/discuss
>> > >
>> > > _______________________________________________
>> > > discuss mailing list     discuss at mpich.org
>> > > To manage subscription options or unsubscribe:
>> > > https://lists.mpich.org/mailman/listinfo/discuss
>> >
>> > --
>> > Pavan Balaji  ✉️
>> > http://www.mcs.anl.gov/~balaji
>> >
>> > _______________________________________________
>> > discuss mailing list     discuss at mpich.org
>> > To manage subscription options or unsubscribe:
>> > https://lists.mpich.org/mailman/listinfo/discuss
>> >
>>
>> --
>> Pavan Balaji  ✉️
>> http://www.mcs.anl.gov/~balaji
>>
>>
>
> _______________________________________________
> discuss mailing list     discuss at mpich.org
> To manage subscription options or unsubscribe:
> https://lists.mpich.org/mailman/listinfo/discuss
>



-- 
Jeff Hammond
jeff.science at gmail.com
http://jeffhammond.github.io/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpich.org/pipermail/discuss/attachments/20150403/285ada90/attachment.html>
-------------- next part --------------
_______________________________________________
discuss mailing list     discuss at mpich.org
To manage subscription options or unsubscribe:
https://lists.mpich.org/mailman/listinfo/discuss