[Mpi-forum] First reading: MPI_Count

Thu Mar 17 18:05:57 CDT 2011

Hi Adam,

Thanks for the feedback, comments inline.

Adam T. Moody wrote on Wed, 16 Mar 2011 at 17:20:42

> Wow, I should have proof-read my email first.  Lots of typos.  See
> inlined fixes for these.
> -Adam
> 
> Adam T. Moody wrote:
> 
>> Hi Jeff,
>> Ugh, this whole chapter (not the count ticket itself) needs major
>> 
> this whole chapter = the datatypes chapter.
> 
>> editing.  It's poorly organized and it talks about and uses deprecated
>> concepts all over the place.  I'll work with Quincey to propose a better
>> version (along with a full set of MPI_Count datatype calls).
>> 
>> Here are some comments for the count ticket.
>> 
>> p 16, line 15
>> Change
>>    "Derived datatypes can be created representing more elements than
>> can be encoded in a C int or Fortran INTEGER.  MPI_GET_COUNT,
>> MPI_GET_ELEMENTS, and associated functions cannot properly express
>> these quantities.  To overcome this limitation, these quatities are
>> declared to be INTEGER (KIND=MPI_COUNT_KIND) in Fortran.  In C, one
>> uses MPI_Count." to
>>    "As described above, MPI defines one type to address locations
>> within memory and another type to address locations within a file.
>> However, at times, one needs a single type that can be used to address
>> locations within either memory or a file.  Furthermore, one needs this
>> 
> or a file, and furthermore, one needs this type to encode any value
> stored in a C int or Fortran INTEGER.

How about:
"As described above, MPI defines one type (MPI_Aint) to address locations within memory and another type (MPI_Offset) to address locations within files.  In addition, some MPI procedures use count arguments that represent a number of MPI datatypes on which to operate.  At times one needs a single type that can be used to address locations within either memory of files as well as express count values.  The datatype of such an argument is MPI_Count in C, and INTEGER(KIND=MPI_COUNT_KIND) in Fortran. These types must have the same width and encode values in the same manner such that count values in one language may be passed directly to another language without conversion."

This is more in line with the descriptions for MPI_Aint and MPI_Offset and more explicit as to the motivation, but without the explicit reference to MPI procedures.

>> type to also any value stored in a C int or Fortran INTEGER.  For this,
>> MPI defines the datatype MPI_Count in C and INTEGER
>> (KIND=MPI_COUNT_KIND) in Fortran."
>> 
>> p 16, line 23-24
>> Change
>>    "in a variable of type C int, MPI_Aint, MPI_Offset, or Fortran
>>    INTEGER." to "in a variable of type int, MPI_Aint, or MPI_Offset in
>>    C and Fortran
>> INTEGER, INTEGER(KIND=MPI_ADDRESS_KIND), or INTEGER
>> (KIND=MPI_OFFSET_KIND) in Fortran."
>> 
> in C and of type INTEGER, INTEGER(KIND=MPI_ADDRESS_KIND), or INTEGER
> (KIND=MPI_OFFSET_KIND) in Fortran.

Sounds good.

>> p 99, line 14-18
>> The whole paragraph is all about the old stuff, which just confuses a
>> new reader.  I would just drop it (or move it toward the end), and
>> replace it with something like:
>>    "The following functions return the lower bound and the extent of a
>> datatype."

This paragraph was there already, and I wanted to minimize the changes:  I simply updated the text to reference the _x version too.  I'm reluctant to remove the whole paragraph - it should be no more confusing than the text that's already in MPI 3.0 draft 1.

> It turns out that a statement like this one is listed below the
> functions.  No need to list it twice, so either drop this one or drop
> the similar statement after the functions.
> 
>> If on the otherhand we want to leave, it there are some typos (extra
>> period after MPI_TYPE_EXTENT

Thanks, fixing this.

>> and "address sized integers" probably
>> means MPI_ADDRESS_KIND, so we should just say "larger sized integers"
>> or something like that):

INTEGER(KIND=MPI_ADDRESS_KIND) may not be larger than INTEGER.  In any case, "address sized integers" is existing text.

>>    "MPI_TYPE_EXTENT. and also return address sized integers" -->
>> "MPI_TYPE_EXTENT and also return larger sized integers"
>> I vote to just drop and replace it, though.

I think dropping this would belong in a different 'cleanup the text' ticket.

>> Question: What if MPI_TYPE_GET_EXTENT overflows?

Is MPI_UNDEFINED a legit value to return in this case?  The current standard doesn't define overflow semantics, so I would argue that this isn't a deficiency in this ticket.

However, should we deprecate MPI_TYPE_GET_EXTENT since MPI_TYPE_GET_EXTENT_X supersedes its functionality?

>> p 100, line 48
>>    "MPI_TYPE_GET_TRUE_EXTENT and ..." --> "The functions
>> MPI_TYPE_GET_TRUE_EXTENT and ..."

Ok.

>> p 105, line 27
>>    "query function MPI_GET_ELEMENTS." --> "query functions
>> MPI_GET_ELEMENTS or MPI_GET_ELEMENTS_X."

Ok.

>> p 106, line 20
>>    "the MPI_GET_COUNT sets the value of count to" --> "the function
>> sets the value of count to"

No, this paragraph is discussing MPI_GET_ELEMENTS and MPI_GET_ELEMENTS_X, so using 'the function' is ambiguous, especially since it's referring to MPI_GET_COUNT.

>> p 106, line 20 Move sentence about overflow up to other sentence about
>> MPI_UNDEFINED, and reword it a bit.

First sentence about MPI_UNDEFINED relates to MPI_COUNT (odd place for it if you ask me, but that's the way the text is setup today.   Ideally the whole sentence on line 19 "If the number of basic elements ... MPI_GET_COUNT sets the value of count to MPI_UNDEFINED" would be in the text describing MPI_GET_COUNT.

>>    "Furthermore, if the number of basics elements is an integral number
>> of datatype copies but this magnitude of this value exceeds the limits
>> of the count parameter, then the function sets the value of count to
>> MPI_UNDEFINED."

The "is an integral number of datatype copies" bit applies to MPI_GET_COUNT.

> number of *basic* elements ... copies but *the* magnintude of this ...

How about "If the number of basic elements exceeds the limits of the count parameter, then the function sets the value of count to MPI_UNDEFINED."?

Thanks,
-Fab

> 
>> -Adam
>> 
>> 
>> 
>> Jeff Squyres wrote:
>> 
>> 
>> 
>>> PDFs have been attached to the 2 MPI_Count tickets for a formal
>>> reading at the Chicago Forum meeting in 2 weeks:
>>> 
>>> - General MPI_Count ticket
>>> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/265
>>> - "W" versions of some collectives
>>> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/269
>>> 
>>> Remember that the solution we're proposing here is the "minimal"
> MPI_Count approach: adding a small number of new functions that take
> MPI_Count arguments so that MPI can claim to fully support arbitrary-sized
> counts.
>>> 
>>> Enjoy your light reading.  :-)
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
>> _______________________________________________
>> mpi-forum mailing list
>> mpi-forum at lists.mpi-forum.org
>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
>> 
>> 
> 
> _______________________________________________
> mpi-forum mailing list
> mpi-forum at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum