Subject: MPI_GET_COUNT, again

From: [email-masked] (Marc Snir)
Date: Thu, 06 Jan 94 19:42:02 -0500

-:) -:) -:) -:) -:)

Possible alternative implementations:

1.  Leave everything as is.

2.  Have count computed by the receive and stored in status.
Then GET_COUNT does not need a datatype argument, and could be
actually an access to a field of status, whereas GET_ELEMENT stays as
it is now.  Additional overhead of, say, 30 cycles per receive.

3.  Have both count and #elements computed by the receive and
stored in status.   Additional overhead of, say, #element cycles per
receive.

Then, if we change (options 2 or 3), we need to decide what to do
with PROBE:

A.  Have probe carry a datatype -- not pleasant because we may not
know yet which datatype to use; we will need to probie again and
again.

B.  Leave a version of GET_COUNT and/or GET_ELEMENTS that have a
datatype argument, in addition to the direct access to a status
count field.

I don't like 3: counting number of (base) elements may be a
significant overhead, and might be seldom needed.  This leaves

1: use GET_COUNT(status, datatype) and GET_ELEMENT(status, datatype)
when count is undefined.

2B:  status.count is OK after receive; GET_COUNT(status,datatype)
can always be used, in particular after PROBE.
Use GET_ELEMENT(status, datatype) when count is undefined.

---

From: [email-masked] (James Cownie)
Date: Fri, 7 Jan 1994 10:49:00 +0000

I'll run over what I think the arguments and objectives are here,
mostly to clarify them to myself ! Please correct me if I'm wrong :-(

Objectives
==========

1) Access to status should be CHEAP. 
   (This is the reason for having store for the status allocated by
    the user, we want to avoid calls to the MPI system as far as
    possible, and especially extra calls on each communication op).

2) You should only have to pay for status values if you use them.
   (We want to avoid a large cost of calculating COUNT or ELEMENTS
   if you never use these values).

Route to where we are now
=========================

Given that we want to make access to status fields as cheap as
possible, it seems reasonable to DEFINE at least a part of the status
structure, so that the user can access the fields directly. (This is
more important in Fortran, in C it can be hidden in a macro, but in
Fortran this option is not available, and we can replace a real
function call by an inline array access if we expose the structure.)

Once we accept this, then we have to define which of the values
accessable from the status object are truly stored in it (and
therefore rapidly accessable as structure dereference), and which
values really do need calculation at the point of reference.

Currently we have the following enquiries on the status object
(I may have missed some... beware !)

GET_ELEMENTS		Leaf element count
GET_COUNT		Top datatype count
GET_SOURCE		Rank of sender
GET_TAG			Tag of message

I think SOURCE and TAG are uncontentious, a receive or probe must know
these values, so there is no problem in putting them into the status
object and allowing the user direct access to them.

COUNT and ELEMENTS are a different kettle of fish for the following
reasons
1) They both depend on the datatype used to interpret the message.
2) They may either or both be expensive to calculate.	

Since PROBE does not take a datatype (and I believe this is
*correct*), it cannot calculate either of these and store the result
in the status object. Therefore we *cannot* allow direct access to a
structure field for these values. This seems correct if we're trying
to achieve the second objective too. If the user can directly access
these values they must always have been calculated and stored, BUT we
believe calculating them may be expensive, therefore it should be
postponed until we know the user wants the value. 

Note that this argument applies to RECEIVE as well. It is NOT solely
PROBE which leads to this result. 

Conclusion
==========

1) GET_TAG and GET_SOURCE could be replaced by named fields (or fixed
   offsets) in the status object.
2) GET_COUNT and GET_ELEMENTS should both be "functions", and not
   status object fields.
3) GET_COUNT and GET_ELEMENTS both need the datatype argument.
   (This is clear if the op was PROBE: there is no datatype lying
   around to use. It is also the case for RECEIVE, because we want to
   allow implementation freedom, and the implementation will probably
   only store one of the two values (or maybe even a more fundamental
   value such as byte count), and evaluate the other as needed)

Extreme implementations
=======================

1) Do it all in receive

   Receive always evaluates COUNT and ELEMENTS, stashes reference to datatype in
   status object as well. Probe stashes byte count.

   GET_COUNT and GET_TAG check datatype given matches one in status
   object and return value, else (probe case) calculate required
   value from  byte count.
   First half can be done in a macro in C, second half will need
   function call.

   Costs :   Calculating both values on every receive
   Benefits: The actual GET_COUNT will be quick after a receive
   Dangers:  Need to be careful comparing stashed datatype with one
             given at GET time. User may have deleted and re-created
             datatypes in-between receive and GET.
   
2) Do nothing in receive

   Both receive and probe simply stash a byte count in the status object.

   GET_COUNT and GET_ELEMENTS both calculate their result from byte
   count.
		
   Costs :   Calculating the value when needed
   Benefits: No work is done until required
   Dangers:  None ?

Intermediate implementations are possible where (say) COUNT is
evaluated by receive but ELEMENTS is not (or the converse). In any
case to get PROBE to work we *must* have the datatype in these
routines, and have them as functions.

Ultimate conclusion
===================

GET_COUNT and GET_ELEMENTS in the draft are fine !
GET_TAG   and GET_SOURCE   could go away if we want to expose
                           something about the status object.	

-- 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]