[Mpi-forum] use of communicator in MPI_Pack and MPI_Unpack

[Thakur, Rajeev]

Your understanding is correct in that the communicator you pass needs to contain the processes to which the message is sent or received from. The standard is saying it in a simple way.

But I would suggest reconsidering whether you really need pack and unpack in the first place. They are rarely used functions, and there is an associated performance penalty. You could try sending the messages directly, e.g., by using derived datatypes if the data is noncontiguous.

Rajeev 


> On Feb 17, 2016, at 8:38 PM, Michael Rezny <michael.rezny at monash.edu> wrote:
> 
> Hi Rajeev,
> thanks for the prompt response.
> 
> I am attempting to ensure that our code conforms to the standard.
> 
> Would it be correct to say that, for the MPI standard, the communicator used in MPI_Pack must
> be a superset of the ranks in the communicator used subsequently by MPI calls that use the packed buffer?
> 
> And likewise, is it correct to state that MPI_Unpack must use a communicator that is a superset of the communicator used to
> receive or create the buffer that is input to MPI_Unpack?
> 
> If that is the case, then would MPI_COMM_WORLD always bea valid option for use as a communicator
> in MPI_Pack and MPI_Unpack?
> 
> Then, as you said, in a homogeneous system, there should be no disadvantage in specifying
> MPI_COMM_WORLD.
> 
> Perhaps the standard and man pages for MPI_Pack could be restated:
> >        The comm argument must include all (be a superset) of all the communicator"s"  that will be
> >        subsequently used for sending the packed message.
> 
> And something similar for MPI_Unpack.
> 
> kindest regards
> Mike
> 
> On 18 February 2016 at 12:57, Thakur, Rajeev <thakur at mcs.anl.gov> wrote:
> You can use MPI_COMM_WORLD as the communicator. If you are running on a homogeneous system, there shouldn’t be any performance issue in using MPI_COMM_WORLD as the communicator either.
> 
> Rajeev
> 
> > On Feb 17, 2016, at 6:09 PM, Michael Rezny <michael.rezny at monash.edu> wrote:
> >
> > Hi,
> > I have a question regarding the use of a communicator in MPI_Pack and MPI_Unpack.
> > I have googled and search the MPI mailing lists but haven't found an answer.
> >
> > The OpenMPI man page for MPI_Pack states:
> >        The comm argument is the  communicator  that  will  be
> >        subsequently used for sending the packed message.
> >
> > And something similar for MPI_Unpack.
> >
> > Which seems to reflect what is defined in the MPI standards.
> >
> > Basically, what I would like to do is to have an MPI rank as a coupler.
> > That is, receiving a packed message from one application and
> > passing it to another application.
> >
> > Comm_A would be the ranks of application A plus the coupler and
> > Comm_B would be the ranks of application B plus the coupler.
> >
> > In this case, MPI_COMM_WORLD = Comm_A U Comm_B.
> >
> > I would like to have a solution that does not have the coupler unpacking
> > the buffer received from application A and then packing it to send it to application B
> >
> > I just found a very nice explanation of the need for a communicator in Pack / Unpack on page 135 of Using MPI Portable Parallel Programming with the Message-Passing Interface
> > second edition by Gropp, Lusk, and Skjellum.
> >
> > If I understand this correctly, it would be legal to use MPI_COMM_WORLD as the communicator
> > for MPI_Pack and MPI_Unpack. The only downside is that one might not get the optimal performance.
> >
> > The alternative we are using is to use MPI_Pack_external and MPI_Unpack_external
> > which requires no communicator. But the downside is that on homogeneous little-endian HPCs,
> > this will always entail byte swapping on packing and unpacking.
> >
> > So my question is: What is the correct and optimal way to implement passing packed messages
> > in the coupling example described above?
> >
> > kindest regards
> > Mike
> > _______________________________________________
> > mpi-forum mailing list
> > mpi-forum at lists.mpi-forum.org
> > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
> 
> _______________________________________________
> mpi-forum mailing list
> mpi-forum at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
> 
> _______________________________________________
> mpi-forum mailing list
> mpi-forum at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum