Subject: Re: Packing/unpacking routines

From: [email-masked] (Rolf Hempel)
Date: Fri, 28 Jan 1994 08:22:01 GMT

I think the compromise of using the target address MPI_ANY_PROC in cases
where you want to reuse the send buffer is okay. Since the communicator
is still specified, the implementation can choose the canonical
representation within that communicator, which means no data conversion
if all processors have the same data representation. This way the XDR
translation only occurs in heterogeneous systems where the overhead
somehow has to be paid anyway. It would certainly not be acceptable if
XDR had to be used in every call to a pack/unpack routine.

Paul made a valid point with his suggestion to use two arguments for
size_so_far instead of an inout argument, since we tried to avoid
inouts for scalar arguments throughout MPI. Nevertheless, I sympathize
with the inout in this case, because this is just a counter which the
user will not be likely to use for other purposes in between calls.
Making it an inout shortens the argument lists. On the other hand,
making it two arguments in almost all cases will lead to the ugly 
Fortran style suggested by Paul (the same actual argument bound to two
function arguments).

I have no strong opinion about Paul's proposed restriction that the
buffer must be unpacked exactly the same way as it was packed.
If the ease of porting codes from existing interfaces to MPI is our
main reason for including the buffering routines, then this restriction
would not be too bad, because that's exactly how you would use them,
anyway. However, together with Rusty I don't see the benefits resulting
from that restriction. Could you please explain it to us, Paul?

- Rolf

---

From: <[email-masked]>
Date: Fri, 28 Jan 94 09:59:21 -0800

> Date: Fri, 28 Jan 1994 08:22:01 GMT
> From: [email-masked] (Rolf Hempel)
> To: [email-masked]
> Subject: Re: Packing/unpacking routines

> from that restriction. Could you please explain it to us, Paul?

No, I can't :-).
I don't see any clear benefits either, unless the first restriction (that
packing start at zero) is rejected. If we are going to restrict use of pack
and unpack for the benefit of the implementation, it seems like an obvious
restriction to propose. It might make implementation of things like strict
type checking easier. But I can't think of anything I would want to do in an
implementation that couldn't be done without the restriction.

So to further explore the specification space let me propose an alternative
anti-restriction, which requires the implementation to be flexible:

-2. An application is allowed to pack and unpack a buffer in any manner as
long as you start at zero and the basic datatypes match.

For example, if you pack a buffer like this:

	pack	2 int
	pack	7 real
	pack	3 real

you can unpack it like this if you want:

		count  type	size_so_far in		size_so_far out
	unpack	   1	int		0			a
	unpack	   1	int		a			b
	unpack	   5	real		b			d
	unpack	   5	real		d			e
	unpack	   1	(1 int, 1 real)	a			c
	unpack	   9	real		c			e
	unpack	   1	(1 int, 5 real)	a			d

Note in this example that parts of the buffer are unpacked more than once
without starting back at zero, and that different ways to unpack ending at the
same place return the same output size_so_far. Any of the unpack calls could
be replaced by unpack_size calls to just get the size_so_far output values.

I can't think of any problems implementing to this spec.

> - Rolf

Paul