[Mpi3-bwcompat] MPI_Count Ticket 265 feedback

[Jeff Squyres]

On Apr 11, 2011, at 10:19 PM, Solt, David George wrote:

> We have a call scheduled this Friday, but we can get things rolling via e-mail before then.

Don't forget that we need to get 4 reviews from every chapter, too.  :-\

That will suck -- please add this to the list of things to discuss on Friday.  We need to start hitting up lots of chapter committees for reviews...!

>>> Page9_at_30: For backward compatibility, many MPI routines use int in C or INTEGER in Fortran as count arguments.
> 
> Hold on... looking for a 10 foot pole.... I'm not sure I like my own suggestion, but here it is:  "Most MPI routines use int in C or INTEGER in Fortran as count arguments rather than MPI_Count.  Routines use MPI_Count as the type for the count argument where they are deemed most likely to exceed the storage capacity of a int or INTEGER."

I honestly forget what this was for -- are we adding text to the rationale here?

>>> Page9_at_19: ...count values, and that type is MPI_Count...
> 
> This change makes no sense to me.   The very next sentence says, "The datatype of such an argument is MPI_Count...".   Does someone remember what this was about?

Agreed -- seems non-sensical.

>>> Page9_at_29: confusion about 'type map' applying to memory only, not file view
> 
> I don't remember the rationale for our rationale :).   It seems to say, "Count values need to be big enough to hold any count values".  

Yes.  Specifically, it's explaining why we need it to be the largest of all types (including file offsets, which some people might question unless further clarification is provided).

> Even if we changed it to "The storage used for storing MPI_Count values needs to be large enough to hold any count values" doesn't seem any more useful a statement.   Maybe this should be something of the form "Advice to Implementers:  The larger the storage use for MPI_Count, the larger the type maps an application can create for working with large files and message data. 

No, I think the point is to provide concrete cases where counts need to be used, and are currently potentially *mis*used by the existing API functions -- e.g., file type maps.

>>> Page120_at_38: Use similar wording to previous "limits" wording might be better (more consistent)
>>> Need to mention overflow for MPI_GET_COUNT?  One could use MPI_STATUS_SET_ELEMENTS_X to overflow MPI_GET_COUNT.
> 
> If the number of basic elements received exceeds the limits of the count parameter, then MPI_PACK_SIZE set the value of count to MPI_UNDEFINED.
> 
> For the MPI_GET_COUNT, it already says this:
> 
> "(We shall later see, in Section 4.1.11, that MPI_GET_COUNT
> may return, in certain situations, the value MPI_UNDEFINED.)".   Does that cover it or should we replace it with:

I don't think it covers it, because 4.1.11 doesn't say anything about overflow; it talks about other cases where UNDEFINED can be returned.

> If the number of basic elements received exceeds the limits of the count parameter, then MPI_GET_COUNT set the value of count to MPI_UNDEFINED.
> 
> I don't think we have to distinguish between "received" and "set by MPI_STATUS_SET_ELEMENTS[X], since this is intended to implement as generalized request receive which is still a form of a "receive".

Aside from minor grammar quibbles, looks ok to me.


-- 
Jeff Squyres
jsquyres_at_[hidden]
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/