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

Re: [Mpi-comments] Typo in "resultlen" in MPI_Get_library_version
by Rolf Rabenseifner 30 Nov '12

30 Nov '12

Dear Jeremiah, thank you for this catch. I already corrected it in the errata ticket #345 https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/345 There are several other errors with respect to Fortran also corrected. Thank you for your help and best regards Rolf ----- Original Message ----- > From: "Jeremiah Willcock" <jewillco(a)osl.iu.edu> > To: mpi-comments(a)mpi-forum.org > Sent: Thursday, November 29, 2012 8:57:47 PM > Subject: [Mpi-comments] Typo in "resultlen" in MPI_Get_library_version > In the two Fortran versions of MPI_Get_library_version (page 336 in > the > final 3.0 standard), "resultlen" is spelled as "resulten" on lines 17 > and > 22. It is also misspelled on line 13 of page 738 and line 39 of page > 773 > (the language binding summaries for those two Fortran bindings). > > -- Jeremiah Willcock > _______________________________________________ > 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: Room 1.307)

1 0

Typo in "resultlen" in MPI_Get_library_version
by Jeremiah Willcock 29 Nov '12

29 Nov '12

In the two Fortran versions of MPI_Get_library_version (page 336 in the final 3.0 standard), "resultlen" is spelled as "resulten" on lines 17 and 22. It is also misspelled on line 13 of page 738 and line 39 of page 773 (the language binding summaries for those two Fortran bindings). -- Jeremiah Willcock

1 0

Re: [Mpi-comments] Collective operations and synchronization
by Jeremiah Willcock 25 Nov '12

25 Nov '12

On Sun, 25 Nov 2012, William Gropp wrote: > You are reading more into the "as if" text than was intended by the MPI > Forum. For example, the "as if" text for MPI_Scatter was meant only to > describe the data that was moved, not the synchronization behavior. > You are correct that this is not made clear in the text. The MPI Forum > did not intend to constrain the algorithm choice, and in fact, we have > made a point of saying that users should not expect any synchronization > beyond what is *explicitly* described (the as if text doesn't count as > an explicit description, as that was, as I noted above, intended only to > describe what data was moved and to where, not the algorithm or details > of synchronization. That was something I wasn't sure of -- whether the synchronizations that are required are actually intended. I would like it if at least the All* and similar collectives were defined to include full barriers, since they would most likely (but don't need to) be implemented that way. -- Jeremiah Willcock > > > On Nov 25, 2012, at 3:38 PM, Jeremiah Willcock wrote: > >> These questions/comments relate to the final MPI 3.0 specification at <URL:http://www.mpi-forum.org/docs/mpi-3.0/mpi30-report.pdf>. All of these comments relate to collectives on intracommunicators; collective semantics on intercommunicators are very different, but similar issues are likely to occur in that case as well. >> >> It seems to be weakly specified which synchronization behavior can be inferred from various collective operations. For example, does MPI_Reduce not complete on the root unless it has been entered on each other process in the communicator? Although it would be nearly impossible to do otherwise in a general-purpose implementation, I could imagine compiler-based optimizations in which the compiler determines that certain processes will contribute fixed values and thus does not send messages from those processes. Line 8 of page 40 appears to prevent this type of optimization (removing messages completely without coalescing them into other messages) for point-to-point communication. Also, seemingly related collectives have different synchronization behavior stated: >> >> 1. MPI_Gather is required to have the synchronization described above by lines 11-19 of page 150, while MPI_Reduce is not required to have it. >> >> 2. MPI_Scatter is required to wait on every non-root process until the root enters it (line 45 of page 159-line 3 of page 160), while the specification of MPI_Bcast does not require this. Note that line 10 of page 218 does not seem to apply to this case, since that text appears to be about whether MPI_Bcast waits to complete on the root until the other processes have reached it (the converse of what MPI_Scatter requires). >> >> 3. MPI_Allgather (lines 40-45 of page 165) and MPI_Alltoall (lines 42-48 of page 168) are required to act as barriers, while MPI_Allreduce is not. MPI_Reduce_scatter_block has non-normative text (lines 11-15 of page 191) stating that it is "equivalent" to MPI_Reduce + MPI_Scatter, which means that the root must reach it before other processes complete it but does not require a full barrier unless MPI_Reduce has stronger synchronization behavior. >> >> Thus, seemingly similar collectives appear to have different constraints on synchronization. The place in which this matters is in certain algorithms for distributed computing that use an operation such as MPI_Allreduce or its non-blocking equivalent to act as both a reduction operation and as a full barrier, which seems "obviously" correct but does not seem to be by the strict wording of the standard. >> >> Am I understanding the wording correctly? Are the descriptions given above what is desired for those collectives that do have synchronization requirements given? Should the others be strengthened, perhaps using "as if" versions of their "obvious" implementations? >> >> -- Jeremiah Willcock >> _______________________________________________ >> 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] Collective operations and synchronization
by William Gropp 25 Nov '12

25 Nov '12

You are reading more into the "as if" text than was intended by the MPI Forum. For example, the "as if" text for MPI_Scatter was meant only to describe the data that was moved, not the synchronization behavior. You are correct that this is not made clear in the text. The MPI Forum did not intend to constrain the algorithm choice, and in fact, we have made a point of saying that users should not expect any synchronization beyond what is *explicitly* described (the as if text doesn't count as an explicit description, as that was, as I noted above, intended only to describe what data was moved and to where, not the algorithm or details of synchronization. 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 Nov 25, 2012, at 3:38 PM, Jeremiah Willcock wrote: > These questions/comments relate to the final MPI 3.0 specification at <URL:http://www.mpi-forum.org/docs/mpi-3.0/mpi30-report.pdf>. All of these comments relate to collectives on intracommunicators; collective semantics on intercommunicators are very different, but similar issues are likely to occur in that case as well. > > It seems to be weakly specified which synchronization behavior can be inferred from various collective operations. For example, does MPI_Reduce not complete on the root unless it has been entered on each other process in the communicator? Although it would be nearly impossible to do otherwise in a general-purpose implementation, I could imagine compiler-based optimizations in which the compiler determines that certain processes will contribute fixed values and thus does not send messages from those processes. Line 8 of page 40 appears to prevent this type of optimization (removing messages completely without coalescing them into other messages) for point-to-point communication. Also, seemingly related collectives have different synchronization behavior stated: > > 1. MPI_Gather is required to have the synchronization described above by lines 11-19 of page 150, while MPI_Reduce is not required to have it. > > 2. MPI_Scatter is required to wait on every non-root process until the root enters it (line 45 of page 159-line 3 of page 160), while the specification of MPI_Bcast does not require this. Note that line 10 of page 218 does not seem to apply to this case, since that text appears to be about whether MPI_Bcast waits to complete on the root until the other processes have reached it (the converse of what MPI_Scatter requires). > > 3. MPI_Allgather (lines 40-45 of page 165) and MPI_Alltoall (lines 42-48 of page 168) are required to act as barriers, while MPI_Allreduce is not. MPI_Reduce_scatter_block has non-normative text (lines 11-15 of page 191) stating that it is "equivalent" to MPI_Reduce + MPI_Scatter, which means that the root must reach it before other processes complete it but does not require a full barrier unless MPI_Reduce has stronger synchronization behavior. > > Thus, seemingly similar collectives appear to have different constraints on synchronization. The place in which this matters is in certain algorithms for distributed computing that use an operation such as MPI_Allreduce or its non-blocking equivalent to act as both a reduction operation and as a full barrier, which seems "obviously" correct but does not seem to be by the strict wording of the standard. > > Am I understanding the wording correctly? Are the descriptions given above what is desired for those collectives that do have synchronization requirements given? Should the others be strengthened, perhaps using "as if" versions of their "obvious" implementations? > > -- Jeremiah Willcock > _______________________________________________ > mpi-comments mailing list > mpi-comments(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-comments

1 0

Collective operations and synchronization
by Jeremiah Willcock 25 Nov '12

25 Nov '12

These questions/comments relate to the final MPI 3.0 specification at <URL:http://www.mpi-forum.org/docs/mpi-3.0/mpi30-report.pdf>. All of these comments relate to collectives on intracommunicators; collective semantics on intercommunicators are very different, but similar issues are likely to occur in that case as well. It seems to be weakly specified which synchronization behavior can be inferred from various collective operations. For example, does MPI_Reduce not complete on the root unless it has been entered on each other process in the communicator? Although it would be nearly impossible to do otherwise in a general-purpose implementation, I could imagine compiler-based optimizations in which the compiler determines that certain processes will contribute fixed values and thus does not send messages from those processes. Line 8 of page 40 appears to prevent this type of optimization (removing messages completely without coalescing them into other messages) for point-to-point communication. Also, seemingly related collectives have different synchronization behavior stated: 1. MPI_Gather is required to have the synchronization described above by lines 11-19 of page 150, while MPI_Reduce is not required to have it. 2. MPI_Scatter is required to wait on every non-root process until the root enters it (line 45 of page 159-line 3 of page 160), while the specification of MPI_Bcast does not require this. Note that line 10 of page 218 does not seem to apply to this case, since that text appears to be about whether MPI_Bcast waits to complete on the root until the other processes have reached it (the converse of what MPI_Scatter requires). 3. MPI_Allgather (lines 40-45 of page 165) and MPI_Alltoall (lines 42-48 of page 168) are required to act as barriers, while MPI_Allreduce is not. MPI_Reduce_scatter_block has non-normative text (lines 11-15 of page 191) stating that it is "equivalent" to MPI_Reduce + MPI_Scatter, which means that the root must reach it before other processes complete it but does not require a full barrier unless MPI_Reduce has stronger synchronization behavior. Thus, seemingly similar collectives appear to have different constraints on synchronization. The place in which this matters is in certain algorithms for distributed computing that use an operation such as MPI_Allreduce or its non-blocking equivalent to act as both a reduction operation and as a full barrier, which seems "obviously" correct but does not seem to be by the strict wording of the standard. Am I understanding the wording correctly? Are the descriptions given above what is desired for those collectives that do have synchronization requirements given? Should the others be strengthened, perhaps using "as if" versions of their "obvious" implementations? -- Jeremiah Willcock

1 0

trouble with MPICH_ATTR_FAILED_PROCESSES
by Ma, Zhaoming 16 Nov '12

16 Nov '12

I am trying to use the following to catch failed processes, void* iAttrPtr; MPI::COMM_WORLD.Get_attr(MPICH_ATTR_FAILED_PROCESSES, iAttrPtr); On Linux, the code compiled but produced a Segmentation fault, ===================================================================================== = BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES = EXIT CODE: 11 = CLEANING UP REMAINING PROCESSES = YOU CAN IGNORE THE BELOW CLEANUP MESSAGES ===================================================================================== APPLICATION TERMINATED WITH THE EXIT STRING: Segmentation fault (signal 11) In Visual Studio 2010, the code produces linking error, error LNK2001: unresolved external symbol MPICH_ATTR_FAILED_PROCESSES I am using MPICH2 1.4.1. Your help on this issue will be greatly appreciated. Zhaoming

1 0

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

07 Sep '12

Ok, I'll delete safe. 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 7, 2012, at 1:23 PM, Rolf Rabenseifner wrote: > Sounds good to me. > The tag is still usefull as a security argument: > If one process provides another tag (i.e., a wrong tag), > then this routine may or will produce a deadlock, > similar to pt-to-pt. > > Rolf > > ----- Original Message ----- >> From: "Jim Dinan" <dinan(a)mcs.anl.gov> >> To: mpi-comments(a)lists.mpi-forum.org >> Sent: Friday, September 7, 2012 8:14:29 PM >> Subject: Re: [Mpi-comments] "safe" tag in MPI_Intercomm_create >> I think that we should delete "safe" and leave any further changes for >> MPI-next. >> >> ~Jim. >> >> On 9/7/12 12:44 PM, William Gropp wrote: >>> Good point. This moves this to MPI-next. >>> >>> 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 7, 2012, at 12:22 PM, Rolf Rabenseifner wrote: >>> >>>> 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) >>>> _______________________________________________ >>>> 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) > _______________________________________________ > 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 Rolf Rabenseifner 07 Sep '12

07 Sep '12

Sounds good to me. The tag is still usefull as a security argument: If one process provides another tag (i.e., a wrong tag), then this routine may or will produce a deadlock, similar to pt-to-pt. Rolf ----- Original Message ----- > From: "Jim Dinan" <dinan(a)mcs.anl.gov> > To: mpi-comments(a)lists.mpi-forum.org > Sent: Friday, September 7, 2012 8:14:29 PM > Subject: Re: [Mpi-comments] "safe" tag in MPI_Intercomm_create > I think that we should delete "safe" and leave any further changes for > MPI-next. > > ~Jim. > > On 9/7/12 12:44 PM, William Gropp wrote: > > Good point. This moves this to MPI-next. > > > > 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 7, 2012, at 12:22 PM, Rolf Rabenseifner wrote: > > > >> 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) > >> _______________________________________________ > >> 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 Jim Dinan 07 Sep '12

07 Sep '12

I think that we should delete "safe" and leave any further changes for MPI-next. ~Jim. On 9/7/12 12:44 PM, William Gropp wrote: > Good point. This moves this to MPI-next. > > 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 7, 2012, at 12:22 PM, Rolf Rabenseifner wrote: > >> 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) >> _______________________________________________ >> 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 07 Sep '12

07 Sep '12

Good point. This moves this to MPI-next. 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 7, 2012, at 12:22 PM, Rolf Rabenseifner wrote: > 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) > _______________________________________________ > mpi-comments mailing list > mpi-comments(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-comments

1 0