Subject: pack/unpack routines

From: [email-masked] (Rolf Hempel)
Date: Tue, 8 Feb 1994 09:27:23 GMT

After reading Marc's text on pack/unpack routines, I have a few
comments/questions:

1. From the definitions I conclude that it's allowed to use a regular
   send (without packing), and to receive the message into a character
   string with subsequent unpacking. In many cases one will need the
   unpacking on the receiver side only (because the structure of the
   message is encoded in the message), whereas on the sending side
   the standard send will be okay (and saves additional copying). The
   freedom to match a regular send with an unpack-receive will be very
   appreciated by users in those cases. On the other hand, this puts
   some constraint on how the pack/unpack is implemented, because the
   packed buffer must look the same as the byte stream which is
   produced by the regular send. In particular, it seems to me
   that the pack/unpack routines must be an integral part of the
   MPI implementation, and cannot be written as an add-on library.
   Is this our intention, or do I misunderstand anyhting here?

2. On page 69, second paragraph, (at least in my printout) it says that
   "the comm and source arguments in a call to MPI_UNPACK should match
   the arguments previously used to receive the packed buffer."
   Shouldn't we request that the unpack must use the actual source rank
   of the received message? Assume a heterogeneous process group and a
   wildcard receive. Then the unpack operation must know the exact
   source process for deciding on changes in data representations.
   Thus, a wildcard in the unpack source field will not help.

3. We already had the discussion on multiple destinations for a message.
   Marc suggests that in case of dest = MPI_ANY_DEST a common
   interchange format be used. This is only necessary in case of a
   heterogeneous communicator. Since we don't have a proposal for a
   MPI_ANY_COMM, the communicator must be specified explicitely. Thus,
   the implementation can decide to use XDR or not, depending on the
   uniformity of data representations. This will lead to less overhead
   in perhaps 99 percent of applications.

- Rolf

---

From: [email-masked] (Marc Snir)
Date: Wed, 09 Feb 94 11:58:08 EST

Date: Wed, 09 Feb 94 11:58:08 -0500

Date: Tue, 8 Feb 1994 09:27:23 GMT
From: [email-masked] (Rolf Hempel)
Message-Id: <[email-masked]>
To: [email-masked]
Subject: pack/unpack routines
Cc: [email-masked]

--- It would be quite wasteful to write pack/unpack routines as an
--- add-on library since they need all the derived datatype
--- interpretation machinery that is required for regular
--- communication.  My intention is to have them, indeed, integrated.
--- this requires little additional work, since the default
--- communication mechanism uses pack/unpack in the current
--- Argonne/UMiss/IBM/... implementations.

--- I stand corrected

--- We need a mechanism that does not force the use of XDR, even when
--- communication is between different types of nodes.  Only when
--- the destination type is unknown at pack time, or the same packed
--- message is to be sent to several different destinations, do we
--- want to force the use of a machine indepedent representation,
--- possibly different both form the source and the destination
--- representation.   Therefore, I suggested that the caller
--- explicitly request the use of XDR when it packs, and that the
--- unpack routine similarly ask for use of XDR.  How this request
--- is coded (ANY_SOURCE/ANY_DEST, or ANY_COMM, or ...) is something
--- of secondary importance.

- Rolf

--- Marc