[Mpi-forum] First reading: MPI_Count
Adam T. Moody
moody20 at llnl.gov
Wed Mar 16 19:20:42 CDT 2011
Wow, I should have proof-read my email first. Lots of typos. See
inlined fixes for these.
Adam T. Moody wrote:
>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
> "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."
> "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.
>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
> "in a variable of type C int, MPI_Aint, MPI_Offset, or Fortran INTEGER."
> "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.
>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
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 and "address sized integers" probably means
>MPI_ADDRESS_KIND, so we should just say "larger sized integers" or
>something like that):
> "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.
>Question: What if MPI_TYPE_GET_EXTENT overflows?
>p 100, line 48
> "MPI_TYPE_GET_TRUE_EXTENT and ..." --> "The functions
>MPI_TYPE_GET_TRUE_EXTENT and ..."
>p 105, line 27
> "query function MPI_GET_ELEMENTS." --> "query functions
>MPI_GET_ELEMENTS or MPI_GET_ELEMENTS_X."
>p 106, line 20
> "the MPI_GET_COUNT sets the value of count to" --> "the function
>sets the value of count to"
>p 106, line 20
>Move sentence about overflow up to other sentence about MPI_UNDEFINED,
>and reword it a bit.
> "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
number of *basic* elements ... copies but *the* magnintude of this ...
>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
>>- "W" versions of some collectives
>>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
More information about the mpi-forum