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

Re: [Mpi-comments] "safe" tag in MPI_Intercomm_create
by Rolf Rabenseifner 07 Sep '12

07 Sep '12

If we ever make this routine a nonblocking collective, the tag may be needed again, because I expect that then, no two nonblocking MPI_Intercomm_create can be active with the same tag. This means, one may include backward and future use. It should not be a dummy. It should continue to require to have a valid tag, i.e., in the tag space between 0 and the value returned with inquiring MPI_TAG. Rolf ----- Original Message ----- > From: "William Gropp" <wgropp(a)illinois.edu> > To: "Comments on the MPI Standard" <mpi-comments(a)lists.mpi-forum.org> > Sent: Friday, September 7, 2012 5:55:14 PM > Subject: Re: [Mpi-comments] "safe" tag in MPI_Intercomm_create > Is this an MPI-next or a ticket zero change? Is this a chapter > committee change (I think it should be, but I don't want to make that > call unilaterally)? > > Bill > > William Gropp > Director, Parallel Computing Institute > Deputy Director for Research > Institute for Advanced Computing Applications and Technologies > Paul and Cynthia Saylor Professor of Computer Science > University of Illinois Urbana-Champaign > > > > On Sep 6, 2012, at 5:36 PM, Jim Dinan wrote: > > > Hi Bill, > > > > That's right, the tag argument is vestigial as of MPI 3.0. I agree > > with your suggestion of changing '"safe" tag' to: > > > > dummy - Ignored argument, retained for backward compatibility. > > > > ~Jim. > > > > On 9/6/12 5:02 PM, William Gropp wrote: > >> I noted in ticket #305 that the argument is now ignored and > >> retained only for backward compatibility. Deleting "safe" isn't > >> enough. > >> > >> Bill > >> > >> William Gropp > >> Director, Parallel Computing Institute > >> Deputy Director for Research > >> Institute for Advanced Computing Applications and Technologies > >> Paul and Cynthia Saylor Professor of Computer Science > >> University of Illinois Urbana-Champaign > >> > >> > >> > >> On Sep 6, 2012, at 1:47 PM, Jim Dinan wrote: > >> > >>> Hi All, > >>> > >>> It looks like we forgot to include the removal of the "safe" > >>> qualifier from the tag argument as a part of the change to > >>> MPI_Intercomm_create: > >>> > >>> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/305 > >>> > >>> Specifying that the tag argument must be "safe" was made > >>> unnecessary by this change, since it eliminates the possibility of > >>> interference with user communication. > >>> > >>> ~Jim. > >>> _______________________________________________ > >>> mpi-comments mailing list > >>> mpi-comments(a)lists.mpi-forum.org > >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-comments > >> > >> > >> _______________________________________________ > >> mpi-comments mailing list > >> mpi-comments(a)lists.mpi-forum.org > >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-comments > >> > > _______________________________________________ > > mpi-comments mailing list > > mpi-comments(a)lists.mpi-forum.org > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-comments > > > _______________________________________________ > mpi-comments mailing list > mpi-comments(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-comments -- Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30)

1 0

Re: [Mpi-comments] "safe" tag in MPI_Intercomm_create
by William Gropp 07 Sep '12

07 Sep '12

Is this an MPI-next or a ticket zero change? Is this a chapter committee change (I think it should be, but I don't want to make that call unilaterally)? Bill William Gropp Director, Parallel Computing Institute Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign On Sep 6, 2012, at 5:36 PM, Jim Dinan wrote: > Hi Bill, > > That's right, the tag argument is vestigial as of MPI 3.0. I agree with your suggestion of changing '"safe" tag' to: > > dummy - Ignored argument, retained for backward compatibility. > > ~Jim. > > On 9/6/12 5:02 PM, William Gropp wrote: >> I noted in ticket #305 that the argument is now ignored and retained only for backward compatibility. Deleting "safe" isn't enough. >> >> Bill >> >> William Gropp >> Director, Parallel Computing Institute >> Deputy Director for Research >> Institute for Advanced Computing Applications and Technologies >> Paul and Cynthia Saylor Professor of Computer Science >> University of Illinois Urbana-Champaign >> >> >> >> On Sep 6, 2012, at 1:47 PM, Jim Dinan wrote: >> >>> Hi All, >>> >>> It looks like we forgot to include the removal of the "safe" qualifier from the tag argument as a part of the change to MPI_Intercomm_create: >>> >>> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/305 >>> >>> Specifying that the tag argument must be "safe" was made unnecessary by this change, since it eliminates the possibility of interference with user communication. >>> >>> ~Jim. >>> _______________________________________________ >>> mpi-comments mailing list >>> mpi-comments(a)lists.mpi-forum.org >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-comments >> >> >> _______________________________________________ >> mpi-comments mailing list >> mpi-comments(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-comments >> > _______________________________________________ > 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] "safe" tag in MPI_Intercomm_create
by Jim Dinan 06 Sep '12

06 Sep '12

Hi Bill, That's right, the tag argument is vestigial as of MPI 3.0. I agree with your suggestion of changing '"safe" tag' to: dummy - Ignored argument, retained for backward compatibility. ~Jim. On 9/6/12 5:02 PM, William Gropp wrote: > I noted in ticket #305 that the argument is now ignored and retained only for backward compatibility. Deleting "safe" isn't enough. > > Bill > > William Gropp > Director, Parallel Computing Institute > Deputy Director for Research > Institute for Advanced Computing Applications and Technologies > Paul and Cynthia Saylor Professor of Computer Science > University of Illinois Urbana-Champaign > > > > On Sep 6, 2012, at 1:47 PM, Jim Dinan wrote: > >> Hi All, >> >> It looks like we forgot to include the removal of the "safe" qualifier from the tag argument as a part of the change to MPI_Intercomm_create: >> >> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/305 >> >> Specifying that the tag argument must be "safe" was made unnecessary by this change, since it eliminates the possibility of interference with user communication. >> >> ~Jim. >> _______________________________________________ >> mpi-comments mailing list >> mpi-comments(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-comments > > > _______________________________________________ > 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] "safe" tag in MPI_Intercomm_create
by William Gropp 06 Sep '12

06 Sep '12

I noted in ticket #305 that the argument is now ignored and retained only for backward compatibility. Deleting "safe" isn't enough. Bill William Gropp Director, Parallel Computing Institute Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign On Sep 6, 2012, at 1:47 PM, Jim Dinan wrote: > Hi All, > > It looks like we forgot to include the removal of the "safe" qualifier from the tag argument as a part of the change to MPI_Intercomm_create: > > https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/305 > > Specifying that the tag argument must be "safe" was made unnecessary by this change, since it eliminates the possibility of interference with user communication. > > ~Jim. > _______________________________________________ > mpi-comments mailing list > mpi-comments(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-comments

1 0

"safe" tag in MPI_Intercomm_create
by Jim Dinan 06 Sep '12

06 Sep '12

Hi All, It looks like we forgot to include the removal of the "safe" qualifier from the tag argument as a part of the change to MPI_Intercomm_create: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/305 Specifying that the tag argument must be "safe" was made unnecessary by this change, since it eliminates the possibility of interference with user communication. ~Jim.

1 0

Tags for Nonblocking Collective Operations
by Qingyu Meng 05 Sep '12

05 Sep '12

Draft URL: http://meetings.mpi-forum.org/mpi3.0_draft_2.pdf Page 196 5.12 Nonblocking Collective Operations The proposed MPI-3 non-blocking collective operations are designed for better overlapping computation and communication. The matching of these operations is based on the order of the calls instead of using tags. This limits the possibility to use dynamic code/task execution when the order of calls to collective operations should be decided at run-time. When running with multiple threads, our computational framework, Uintah (www.uintah.utah.edu) has to duplicate MPI communicators to ensure collective messages get to the right buffer. The current draft version of the MPI-3 standard states, ï¿½The use of tags for collective operations can prevent certain hardware optimizations.ï¿½ (Page. 108, Line. 14). However, the standard does allow the use of communicators to match collective operations. Does this usage also prevent certain hardware optimizations? Duplicating communicators for message matching is inefficient, as communicators must be reserved before use and also cause additional overhead. We would like to request further consideration in supporting the use of tags in nonblocking collective operations, to avoid the inefficiencies related to communicator duplication. This would not only benefit our computational framework, but other task-based, parallel frameworks that rely on collective operations as we move toward exascale. Qingyu Meng Scientific Computing and Imaging Institute, University of Utah

1 0

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