Re: [Mpi-comments] Comments on MPI 3.0 draft 2 [part 5]
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
participants (1)
-
Rajeev Thakur