All page references are for the July 8, full draft document.
Sections 6.4.4-11 are Richard Frost's proposal and sections 6.4.12-13
are Marc Snir's proposal. They both propose to use pack/unpack to
create transportable representations. They both do datatype and
Richards also does communicators. They both define the cononical
datatype representation to be the one given in 6.4.2. Marc's allows
packing for transfer within a program without going to a cononical
representation.
I will begin with doing datatypes since this is common to both.
Richard's proposal uses MPI_COMM_NULL to indicate that pack should
pack the datatype instead of the data it represents. Marc's proposal
makes the datatype be a new value of MPI_DATATYPE and makes the inbuf
be the datatype handle. I like Marc's proposal because of the added
features it allows as described below.
Marc allows one to use any current communicator to do the pack. What
this allows is transfering a datatype to another process without
requiring the MPI implementation to go to the cononical
representation. With one sided communications you may want to
transfer a datatype to another process during a run but not need to
have them be cononical because they are not needed after the job. I
like this capability. You cannot do this in Richard's because he sets
the comm to be MPI_COMM_NULL.
Richard's proposal uses MPI_COMM_NULL to get pack to give a cononical
representation. Marc uses a new constant MPI_COMM_UNIVERSAL. I like
Marc's better because it allows for better error checking. With
Richard's you cannot tell accidently sending a freed comm vs. wanted
to do a cononical pack. However, Marc's way also gives an important
capability by not limiting MPI_COMM_UNIVERSAL to MPI_DATATYPE. One
can give any datatype, make inbuf a normal buffer, and give
MPI_COMM_UNIVERSAL. What is returned in outbuf is a cononical
representation of the inbuf. This means one could write the data to a
disk, read it in on another architecture and by appropriately
unpacking can get back the original data as represented on the new
machine. This would be as if you had one big communicator with both
architectures within one MPI job and had sent the data. I think the
ability to get cononical representations of any data is very useful,
for example, for IO. Trying to do this in Richard's is hard since he
uses MPI_COMM_NULL. Thus, I favor both the feature and method used in
Marc's proposal.
Now I turn to the ability to pack a communicator in Richard's
proposal. My big picture question is what are the unique reasons for
this capability. It seems that you are not looking at the opaque
parts of the comm so why have this special function. I think I am
missing the real point here. Help?
I have a few questions/comments about specific aspects:
I am worried about using MPI_COMM_COMPARE in a new way where the
output has a new meaning. In MPI-1 it returns IDENT, SIMILAR, and
UNEQUAL. Here it seems to return "same" if the architecture is
compatible for translation.
The intro says that one could use this to "instantiate an
intercommunicator with the server". I do not see how one can do this
since the later text limits the use to comparisons only.
on p. 148 there is advice to implementors that one could create the
packed representation when MPI_PACK_SIZE is called. Why do it here
instead of at the actual PACK call. It is not communicating at the
PACK so delay should not be critical.
I welcome comments/corrections.
Steve