September 2012 - mpi-comments - mailman3.cels.anl.gov

MPI_WIN_SHARED_QUERY
by Hubert Ritzdorf 04 Sep '12

04 Sep '12

Hi, Page 410, Line 26 should be IN rank rank in the group of window win or MPI_PROC_NULL A reference to MPI_WIN_SHARED_QUERY is missing on Page 612, Line 1 (Fortran support) and Page 614, Line 9 and Line 31. Hubert

1 0

Re: [Mpi-comments] Freeing memory allocated in MPI_WIN_ALLOCATE_SHARED
by Richard Graham 04 Sep '12

04 Sep '12

From: Hubert Ritzdorf [mailto:[email protected]] Sent: Tuesday, September 04, 2012 05:49 AM To: mpi-comments(a)lists.mpi-forum.org <mpi-comments(a)lists.mpi-forum.org> Subject: [Mpi-comments] Freeing memory allocated in MPI_WIN_ALLOCATE_SHARED Hi, is it correct that MPI_Win_free should free the memory allocated in MPI_Win_allocate_shared ? MPI_Win_free (Page 416, Line 5-6) specifies this only for memory allocated by MPI_Win_allocate. I think that an additional reference to MPI_Win_allocate_shared is missing also on Page 420, Line 31, Page 448 Line 25, Page 609 Line 31, Page 613 Line 1, Page 614 Line 9, Page 614 Line 31. Hubert

1 0

Freeing memory allocated in MPI_WIN_ALLOCATE_SHARED
by Hubert Ritzdorf 04 Sep '12

04 Sep '12

Hi, is it correct that MPI_Win_free should free the memory allocated in MPI_Win_allocate_shared ? MPI_Win_free (Page 416, Line 5-6) specifies this only for memory allocated by MPI_Win_allocate. I think that an additional reference to MPI_Win_allocate_shared is missing also on Page 420, Line 31, Page 448 Line 25, Page 609 Line 31, Page 613 Line 1, Page 614 Line 9, Page 614 Line 31. Hubert

1 0

Re: [Mpi-comments] MPI_Get_count_x
by George Bosilca 03 Sep '12

03 Sep '12

Hubert, This function belong to ticket #265 (https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/265) the one adding support for MPI_Count. I think the rationale was the following. If the "compatible" number of top-level elements is greater than an int (this is what MPI_Get_count can safely returns), then MPI_Get_count is supposed to return MPI_UNDEFINED, and the application should fallback on using MPI_Get_elements_X instead. I thought I could provide an implementation for MPI_Get_count_X, but without knowledge about the MPI implementation, or an impressively costly MPI_Type_get_envelope/MPI_Type_get_contents I couldn't figure out how. Moreover, I don't think there is an easy way to distinguish if the MPI_UNDEFINED returned by MPI_Get_count is due to a lack of space for the return type or a mismatch in the size of the data. This should be added to the growing list of things to be fixed post 3.0. Meanwhile, implement your own [expensive] way of parsing datatypes using MPI_Type_get_envelope/MPI_Type_get_contents if you want to implement a really portable library (aka supporting MPI_Count). george. PS: MPI_Type_create_keyval can be helpful here in order to speed things up when a datatype is used multiple times. On Aug 31, 2012, at 16:20 , Hubert Ritzdorf <Hubert.Ritzdorf(a)EMEA.NEC.COM> wrote: > Hi George, > > I know MPI_Get_elements_x (). But Page 483 claims: > > These functions modify the opaque part of status so that a call to > MPI_GET_ELEMENTS or MPI_GET_ELEMENTS_X will return count. MPI_GET_COUNT > will return a compatible value. > > This will not work for large MPI_Count values provided by MPI_SET_ELEMENTS_X > (i.e. MPI_UNDEFINED is returned by MPI_Get_count() in significant use of MPI_SET_ELEMENT_X). > And Page 114 says that function MPI_Get_count has a different behavior than > MPI_GET_ELEMENTS/MPI_GET_ELEMENTS_X. Thus, MPI_GET_COUNT is not obsolete > and application has to develop a separate version of MPI_Get_count_x() if MPI_SET_ELEMENT_X > might be used in the application or a library. > > Hubert > > From: mpi-comments-bounces(a)lists.mpi-forum.org [mpi-comments-bounces(a)lists.mpi-forum.org] on behalf of George Bosilca [bosilca(a)eecs.utk.edu] > Sent: Friday, August 31, 2012 2:26 PM > To: Comments on the MPI Standard > Subject: Re: [Mpi-comments] MPI_Get_count_x > > MPI_Get_elements_x, chap Datatypes page 114 (current make cleandoc). > > george. > > On Aug 31, 2012, at 13:45 , Hubert Ritzdorf <Hubert.Ritzdorf(a)EMEA.NEC.COM> wrote: > >> Hi, >> >> I think, that function >> >> MPI_Get_count_x (const MPI_Status *status, MPI_Datatype datatype, MPI_Count *count) >> >> is missing. After use of function MPI_Status_set_elements_x, MPI_Get_count is possibly not able >> to return a compatible value. This is contradictory to Page 483, Lines 22-33. >> >> Hubert >> >> >> >> _______________________________________________ >> mpi-comments mailing list >> mpi-comments(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-comments > > > > Click here to report this email as spam. > _______________________________________________ > mpi-comments mailing list > mpi-comments(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-comments

1 0

Re: [Mpi-comments] Comments on MPI 3.0 draft 2 [part 5]
by Rajeev Thakur 03 Sep '12

03 Sep '12

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

1 0

Re: [Mpi-comments] Comments on MPI 3.0 draft 2 [part 5]
by Jeremiah Willcock 03 Sep '12

03 Sep '12

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

1 0

Re: [Mpi-comments] Comments on the MPI-3 draft
by Rajeev Thakur 03 Sep '12

03 Sep '12

Reinhold, Thanks to you and your colleagues at LRZ for your careful reading of the draft MPI-3 standard. I have fixed the typos you pointed out in the I/O chapter. [p535:23] Replace "implictly" by "implicitly" (typo) [p542:27-28] Replace "compatiblty" by "compatibility" (typo) Rajeev On Aug 31, 2012, at 9:47 AM, Bader, Reinhold wrote: > Please consult the attached text file. > > Best Regards > > -- > Dr. Reinhold Bader > > Leibniz Supercomputing Centre (http://www.lrz.de) / HPC Support > Tel. +49 89 35831 8825 - Fax +49 89 35831 8625 > > <MPI_3.0_comments.txt>_______________________________________________ > mpi-comments mailing list > mpi-comments(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-comments

1 0

Re: [Mpi-comments] Comments on MPI 3.0 draft 2 [part 5]
by Rajeev Thakur 03 Sep '12

03 Sep '12

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

1 0