Re: [mpich-discuss] How to use non-blocking send/receive without calling MPI_Wait
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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> wrote: Does MPI_Test fit your needs?
--Junchao Zhang
On Thu, Apr 2, 2015 at 7:16 PM, Lei Shi <[email protected]> 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 [email protected] To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss
_______________________________________________ discuss mailing list [email protected] To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss
_______________________________________________ discuss mailing list [email protected] To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss
-- Pavan Balaji ✉️ http://www.mcs.anl.gov/~balaji
_______________________________________________ discuss mailing list [email protected] To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss
-- Pavan Balaji ✉️ http://www.mcs.anl.gov/~balaji
_______________________________________________ discuss mailing list [email protected] To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss
-- Jeff Hammond [email protected] http://jeffhammond.github.io/ _______________________________________________ discuss mailing list [email protected] To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss
participants (1)
-
Jeff Hammond