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

[Rajeev Thakur]

I made only obvious ticket 0 changes. Anything else will have to be looked at by a group for the next version.

> 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?

I don't know. For next version.

> 
>>> 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.

It's more than a typo fix and may introduce a bug of its own unless someone else verifies it. For 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)?

I don't remember the history behind it (1996).

>>> 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).

For next version.

> 
>>> 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.

Yes, particularly since the restriction has been removed for nonblocking sends.


>>> 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).

Next version.

>>> 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?

Next version.

>>> 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?

Again, more than a typo fix. 

>>> 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).

Glad!

>>> 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.

Yes.

>>> 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?

The data item could be part of a derived datatype. This bullet doesn't restrict the use to basic datatypes as item 1 does.

>>> 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?

The first case describes the (obvious) behavior when there is a total of one process opening one file. The second case is when two processes call a collective open (using COMM_WORLD, for example) to open the same file. The third case is when two processes independently open the same file (using COMM_SELF, for example).

> 
>>> 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 ...").

Maybe, but even MPI_Aint doesn't say it should be signed. (In any case, I am not making that change on my own.)

Rajeev