[Mpi-comments] Comments on MPI 3.0 draft 2 [part 5]

[Jeremiah Willcock]

Here are my responses to those, skipping the ones that I don't have any 
comments on:

>> Page 495 lines 11-12: Are there any guarantees about the behavior of
>> MPI_MODE_DELETE_ON_CLOSE if the program exits (normally or abnormally)
>> without explicitly closing the file?
> No

Is that stated explicitly anywhere?

>> Page 499 lines 44-45: Wouldn't using log on the bit to test and then
>> mod and integer division on the amode be simpler than the loop?
>> Floating-point errors might cause trouble there, however, or if one
>> of the masks was not a single bit.
> Maybe, but it is more than a ticket 0 change

Even for an example?  If it is too big of a change, please put it on the
list for the next version.

>> Page 503 lines 22-23: Is this hint intended to say how many devices
>> to use, not how many are in the system?
> No, it is correct. The next hint "striping_factor" says how many
> devices to use.

What is the point of putting in a hint about the system configuration
(which the MPI implementation should be able to get on its own)?

>> Page 506 lines 30-33: Is there an easy way to tell that a datatype is
>> derived?  Is the datatype returned, if derived, guaranteed to be new
>> (and not, for example, one passed into MPI_FILE_SET_VIEW by the
>> user)?
> Yes, using MPI_Type_get_envelope. If derived, the text says, the
> function returns a datatype that the user is responsible for freeing.
> It doesn't talk in terms of new or not.

That seems like it needs advice to users (I didn't know before your
comment how to determine whether a datatype is derived, and the test
might be subtle for people who are not experts in datatype handling in
MPI).

>> Page 508 lines 9-11: Does that mean a buffer being written to a file
>> can't be concurrently sent?  It seems like that restriction may be
>> too strong, especially when you can use a datatype to write the same
>> data to a file more than once in a single operation.
> It would be more than a ticket 0 change.

OK, but it should probably be on the list to look at for the next
version.

>> Page 536 lines 34-35: Unicode has several encoding formats; which one
>> are you intending (UTF-7, UTF-8, UTF-16, UCS-16, UCS-32, or something
>> else)?
> Don't know.

It would be a problem for interoperability of external32 to not have
a normative answer to that.  Also, different Unicode formats change
which code points can be represented (many UCS-2 implementations, for
example, cannot encode code points greather than 0xFFFF, for example;
see http://www.unicode.org/faq/basic_q.html#14).

>> Page 537 lines 9-12: Some of this information (what happens on
>> overflows from down-converting number formats, for example) is
>> normative and should be in the main text.  Also, taking the
>> least-significant bytes of a larger number does not always preserve
>> the sign bit in case of overflows (converting the MPI_INT 32768 to an
>> MPI_INTEGER2 leads to -32768, for example).  Is making sure to
>> preserve the sign bit always the intended behavior?
> Not changed.

Why?

>> Page 538 line 9: Defining wchar as two bytes prevents it from
>> representing all valid Unicode code points (some of them are above
>> 2^16). If such code points are forbidden (even on platforms where
>> wchar_t is 32 bits), be sure to say that explicitly.
> Not changed.

Why?

>> Does the MPI standard say anywhere that a byte is assumed to be 8 bits?
> Don't know.

It turns out that the answer is "yes" (page 25 line 28).

>> Page 541 lines 47-48: Does that mean that point-to-point operations
>> are OK?  Non-collective file I/O?
> Sounds like it.

That seems odd -- I would expect that I/O callbacks would be completely
local and not do I/O themselves.  That might be worth considering for
the next version.

>> Page 542 lines 17-25: The first item in this list appears to be a
>> superset of the third one, and it seems like all of them might be
>> required to be satisfied when applicable (not just "at least one").
> The first one refers to a program using only basic datatypes. The 3rd
> one refers to a program using derived datatypes.

The third bullet point there is still about "predefined datatypes", or
does "data item" refer to an element of a derived datatype?

>> Page 543 lines 4-5: How do you get multiple file handles out of the
>> same collective open of a file?  Accesses from different processes
>> only?  Or can file descriptors be sent between processes?
> Multiple means the return values on different processes.

Does that mean that file handles can be sent between processes?  If not,
why would the behavior of multiple processes accessing the same file
change based on whether the collective open operation returned different
file handles to the different processes rather than returning the same
one everywhere?

>> Page 547 line 10: Is MPI_Offset required to be signed?
> Yes. you can seek backwards from the current location.

That's what I would expect, but that might be worthwhile to say
("MPI_Offset is a <ins>signed</ins> integer type ...").

-- Jeremiah Willcock

On Mon, 3 Sep 2012, Rajeev Thakur wrote:

> Jeremiah,
>               I appreciate your careful reading of the MPI standard (over 800 pages) from front to back. It must have taken many days to read everything and type in all the comments.
>
> I have incorporated your comments on the I/O chapter and sent the revised version to Bill/Jeff/Rich to check in. Attached is my response to your comments. I have incorporated almost all of them.
>
> Thanks again,
> Rajeev
>
>
>