[Mpi-forum] First reading: MPI_Count
Adam T. Moody
moody20 at llnl.gov
Thu Mar 17 20:09:43 CDT 2011
Hi Fab,
No problem. I've inlined some replies.
-Adam
Fab Tillier wrote:
>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.
>
>
Yes, this sounds fine. I wrote my version to avoid the word
"datatype". Memory and files are well-known, but datatypes in the way
MPI uses them are new to most people. Since the concept is not well
defined at this point in the text, I was trying to write something that
avoided using the term. Probably not a big deal to use it though.
I thought about referencing "MPI_Aint" and "MPI_Offset", but those are
really just the C types, not the generic name. I don't know that we
even have a generic (language neutral) term for each concept. And now
that I re-read it, technically, MPI defines more than one type for each,
so my use of "one type" is not quite right either. Maybe modify it a
bit to read something like "MPI defines types to address locations
within memory (e.g., MPI_Aint) ...".
>
>
>>>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.
>
>
That's fine. I'll be putting together a ticket to clean up this
chapter, so I'll address it then.
>
>
>>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.
>
>
Sure, that's fine. I'll try to kill/move this paragraph later in my
'clean up the chapter' ticket.
>
>
>>> "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?
>
>
I would think returning MPI_UNDEFINED would make sense here. We are
adding the MPI_UNDEFINED semantic to a similar query where it didn't
exist before, namely MPI_GET_ELEMENTS (p106, line 22), so why not add it
to GET_EXTENT, GET_SIZE, and GET_TRUE_EXTENT, as well. Maybe we should
push all of this off to an "overflow" ticket?
A separate but related question:
We now have multiple functions that return the constant
"MPI_UNDEFINED". In some cases, the MPI_UNDEFINED is returned in an
int, and in others its returned in an MPI_Count. Internally within the
MPI implementation, MPI_UNDEFINED will be defined some datatype, but it
can't be both. Does it matter that we're using the same constant for
comparison of different datatypes? Hopefully, casting will come to the
rescue, but I haven't thought about this much.
>
>
>>>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.
>
>
You're right. Hmm, I have no idea what I was thinking here.
>
>
>>>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.
>
>
Ah, yes, right again. I think I was mixing the roles of the operations
here, which led to my confusion.
>
>
>>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
>>
>>
>
>_______________________________________________
>mpi-forum mailing list
>mpi-forum at lists.mpi-forum.org
>http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
>
>
More information about the mpi-forum
mailing list