Q: What did we talk about last time? Could you do a brief summary?
A: Last time, we mentioned about the 4 send modes (standard, synchronous, buffered and ready). We also tested the MPI_Issend() and found it is not always synchronous although the function name contains a ‘s’ representing it should be synchronous. Some concepts are clarified, e.g. ‘local/nonlocal send-completion’, ‘send-return’. The non-blocking is mentioned a little bit.
Q: Good. I think if I can design the code very well, I do not need the non-blocking communication, right?
A: Yes, theoretically you can, but it’s very hard for complex communication context. To avoid many design issues or deadlock, I prefer the non-blocking operations, not only for the simpler design, but sometimes, the efficiency is much better than the blocking counterparts.
Q: I know the non-blocking send is MPI_Isend(), right?
A: Right, but not complete. In fact, the non-blocking send also has 4 modes (standard, synchronous, buffered and ready). Last time, in fact, I talked about the non-blocking synchronous send – MPI_Issend(). They are very similar. The difference from blocking send is MPI_I*send() will return immediately.
Q: Are the blocking and non-blocking send and receive compatible with each other?
A: Yes. You can use blocking send to send the data out and the data can be received by a non-blocking receive, and vice versa.
Q: In syntax, what’s the most evident difference between the MPI_Send() and MPI_Isend()?
A: Here I put the MPI Standard 3.0 here:
We can see there is an extra argument of MPI_Isend(), it’s type is MPI_Request.
Q: What’s the MPI_Request type?
A: The MPI_Request is an type for non-blocking communication. It contains some information about the communication associated with this request. Unlike the blocking operator, once it’s returned, the send-buffer is released and ready to be reused. The return of non-blocking operator means nothing, user needs some thing (here the request handle) to track the status of the communication. There is a function named “MPI_Request_get_status()” to let the user to check the status through the request object.
Q: You say the MPI_Request is like a tracker. It means the some variables inside this object wil change with the different communication stages. I think the default/initial value is important because it must represent some default/initial status, right?
A: Good question. In fact, the default value of MPI_Request is not defined. In my computer, it is 0. It is better to set it to be MPI_REQUEST_NULL if necessary. It is a constant number defined in mpi.h file. In the mpich 3.0.2 version, it is
After the tracking is finished, the object needs to be reset(freed) to be MPI_REQUEST_NULL by system or the user.
Q: What will happen if I track a MPI_Request object with value of MPI_REQUEST_NULL?
A: The monitoring flag will be true, which means the request is complete. It sounds weired because how can the tracker report ‘successful’ with a empty request. In fact, it is very useful in some complex situations to make the code more symmetric. You will discover this feature in the future by yourself.
Q: How to release/free the MPI_Request object?
A: If you use MPI_Wait(), it will be freed by the system automatically. If you use MPI_Test(), unless the communication is finished (flag=true), the request will not be freed. If user wants to free it, just use MPI_Request_free(). Here is the code:
The output is
The constant MPI_REQUEST_NULL is 738197504
The s_req is MPI_REQUEST_NULL
got is 1
The s_req is MPI_REQUEST_NULL
We can notice that even the request object is freed immediately after the MPI_Issend() before the receiver starts to receive data, the communication will not fail. The ‘tracker’ will not influence the communication itself.
Q: The non-blocking mode is much flexible than the blocking mode. Now I want to gather some data from N processors, I need to call (N-1) times MPI_Irecv()?
A: No. MPI has the collective communication functions. Here I will only put one which I think the most practical and a little complex. It is MPI_Gatherv():
We can see the proc 0 is the root. Proc 0,1,2 will send different sized data to the root. Each procs prepare the pointer of the send buffer as well as the data count. The ‘recv’, ‘count’, ‘disp’ are only meaningful for the root processor. The ‘count’ and ‘disp’ are both arrays.
Q: Nice, the collective communication saves me much energy. Does it have any drawbacks?
A: It is not flexible. Every processors in the MPI_COMM_WORLD must execute this operator. If you only want the data from the processors with odd ranks, you can not use it directly. Of course, you can always use the send/recv to communicate, but if we want to use the collective communication, we should first put those odd ranks together (maybe create a new group or set to store those ranks) and then call thie collective communication within this group. This capability is also a part of MPI Standard, which will be talked about next time.
Q: Up to now, all the data for communication is just the basic datatypes, e.g. integer, float number, character…, could we communicate the user-defined structure directly between processors?
A: The short answer is NO. Any information must be transformed into several MPI datatypes before communication. However, MPI provides the user a better way to ‘pack’ the user’s own structured data. They are MPI_Pack() and MPI_Unpack(). Each pack can have different types of data. It is not used intensively, here I give the code directly.
Proc 0: the address of i is 140726724892152
Proc 0: the address of a is 140726724892240
Proc 0: position after 1st MPI_Pack is 4
Proc 0: position after 2nd MPI_Pack is 84
Proc 1: After first unpack, the position is 4
Proc 1: The value i is 9527
Proc 1: After second unpack, the position is 84
Proc 1: a=2.13
Proc 1: a=2.23
Proc 1: a=2.33
Proc 1: a=2.43
Proc 1: a=2.53
Proc 1: a=2.63
Proc 1: a=2.73
Proc 1: a=2.83
Proc 1: a=2.93
Proc 1: a=3.03
Q/A: We are actors, see you next time.