Subject: GET_COUNT

From: "Marc Snir ((914) 945-3204 (862)" <[email-masked]>
Date: Mon, 3 Jan 94 20:38:27 EST

cc:gropp at mcs.anl.gov, frankeh
Subject: datatype argument in MPI_GET_ELEMENT
Reply-To: [email-masked]

The two arguments in the favor of current design are:

1. It might be possible to receive messages faster if one does not have to
count elements at receive time  (Paul Pierce made this argument -- Paul are
you on?)  Counterargument:  one just need to store in the datatype the number
of bytes of the datatype and, when receiving, divide total number of bytes
received by datatype length.   Count is quotient, if integer, or MPI_UNDEFINED,
if quotient is not integer.   It seems that the saving is < 10 instructions.
Moreover, one might use a running element count anyhow
for complex datatypes, in order to store data in the right place.

2. Make RECV and PROBE identical.  Otherwise, we still need the GET_COUNT in
its  current form after a call to PROBE.

Comments?  (Including from implementers...)

---

From: <[email-masked]>
Date: Tue, 04 Jan 94 10:32:23 -0800

> From: "Marc Snir ((914) 945-3204 (862)" <[email-masked]>
> 

I find the counterargument adequate. In fact, if you have a GET_COUNT that is
only for RECV and doesn't take a datatype, RECV can simply save the datatype
in the MPI_Status data structure where it can be used by GET_COUNT when
needed. Then you can implement GET_COUNT any way you want. You don't have to
do the divide during the RECV itself.

Of course, this option makes it harder to argue that MPI_Status should be
totally user visible.

> its  current form after a call to PROBE.

The argument for keeping the datatype in GET_COUNT for PROBE is that you can
do one (potentially expensive) PROBE and then test it against one (or more) of
several different datatypes as needed.

I would be happy (because it would make the two calls more consistent and
easier to remember) to make RECV and PROBE the same, so they both take a
datatype. Then, have a simple GET_COUNT that returns the number of elements of
that datatype, plus a GET_COUNT_TYPED that takes a test datatype and returns
the number of elements of the test datatype. Or, we could forget
GET_COUNT_TYPED and force the user to either do multiple PROBE calls for the
same message to get an accurate element count or cheat by using the BYTE
datatype and local knownledge of the datatype size.

We could expose the first few elements of MPI_Status so that you wouldn't need
the extra calls in Fortran. Of course, then you would always have to do the
divide in RECV so the count would be there. I don't think its a big deal.

Paul

---

From: [email-masked] (James Cownie)
Date: Wed, 5 Jan 1994 10:41:08 +0000

I'm pretty much in favour of leaving it the way it is.

As I read him Paul also seems happy with this.

> In fact, if you have a GET_COUNT that is only for RECV and doesn't
> take a datatype, RECV can simply save the datatype in the MPI_Status
> data structure where it can be used by GET_COUNT when needed. Then you
> can implement GET_COUNT any way you want. You don't have to do the
> divide during the RECV itself.

One problem with this is that the user could TYPE_FREE the datatype in
between the receive and the GET_COUNT call. This makes stashing the
type dangerous (note that ref count doesn't work here because the MPI
system can't see creation/deletion of the user allocated status
object, which is where the reference has to live).

In my mind this (and simplifying to a single function rather than two)
was a strong reason for having to give the type even after receive.

-- Jim 
James Cownie 
Meiko Limited			Meiko Inc.
650 Aztec West			Reservoir Place
Bristol BS12 4SD		1601 Trapelo Road
England				Waltham
				MA 02154

Phone : +44 454 616171		+1 617 890 7676
FAX   : +44 454 618188		+1 617 890 5042
E-Mail: [email-masked]   or    [email-masked]