August 2012 - mpi-forum - mailman3.cels.anl.gov

Re: [Mpi-forum] Reserved MPI_ prefix & namespace in C and Fortran
by William Gropp 26 Aug '12

26 Aug '12

I would use "must" instead of "should", esp in reference to the PMPI interface. I'd also reserve all PMPI and MPI names, not just the function/subroutines for PMPI. The intent was always that users avoid these two prefixes for any use; anyone who used them was courting trouble. 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 Aug 26, 2012, at 9:03 AM, Rolf Rabenseifner wrote: > I updated the ticket 343 with the now hopefully final text > for the terms chapter > (after Bronis has moved the tools aspect to MPI-next), > see > https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/343 > and the attached files. > > I hope that now all can agree with this correction of the > existing inconsisteny as detected in the public review > and discussed in the previous emails. > > -------------------------------- > Latest summary of the necessary MPI-2.2 erratum > in Sections 2.6.2 - 2.6.4: > > C: >> "Programs must not declare > names (identifiers), e.g., for variables, functions, > constants, types, or macros, >> beginning with the prefix MPI_." > > Fortran: >> "Programs must not declare > names, e.g., for variables, subroutines, functions, > parameters, derived types, abstract interfaces, or modules, >> beginning with the prefix MPI_. > > and for Fortran also "subroutines and functions" instead of > only "functions" in the sentence about PMPI_. > > C++ (not visible in MPI-3.0 due to removal of C++): >> "Programs must not declare > names (identifiers), e.g., for variables, functions, > constants, types, or macros, >> in the namespace MPI." > > And change-log entry > > Sections 2.6.2 and 2.6.3 on pages 18 and 19, and > MPI-2.2, Section 2.6.2 on page 17, lines 41-42, > Section 2.6.3 on page 18, lines 15-16, and > Section 2.6.4 on page 18, lines 40-41. > This is an MPI-2 erratum: The scope for the reserved prefix MPI_ > and the C++ namespace MPI was extended to any name. > ------------------------------- > > Best regards > Rolf > > > ----- Original Message ----- >> On Sun, 26 Aug 2012, Bronis R. de Supinski wrote: >> >> I think we should defer the issue to MPI Next. >> >> On Sun, 26 Aug 2012, Rolf Rabenseifner wrote: >> >>> Hello Bronis, Kathryn, Dave, >>> >>> Do you agree with Martin's opinion and his suggested addition >>> for the tools chapter? > ... > > -- > 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-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum

1 0

Re: [Mpi-forum] Reserved MPI_ prefix & namespace in C and Fortran
by Rolf Rabenseifner 26 Aug '12

26 Aug '12

I updated the ticket 343 with the now hopefully final text for the terms chapter (after Bronis has moved the tools aspect to MPI-next), see https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/343 and the attached files. I hope that now all can agree with this correction of the existing inconsisteny as detected in the public review and discussed in the previous emails. -------------------------------- Latest summary of the necessary MPI-2.2 erratum in Sections 2.6.2 - 2.6.4: C: > "Programs must not declare names (identifiers), e.g., for variables, functions, constants, types, or macros, > beginning with the prefix MPI_." Fortran: > "Programs must not declare names, e.g., for variables, subroutines, functions, parameters, derived types, abstract interfaces, or modules, > beginning with the prefix MPI_. and for Fortran also "subroutines and functions" instead of only "functions" in the sentence about PMPI_. C++ (not visible in MPI-3.0 due to removal of C++): > "Programs must not declare names (identifiers), e.g., for variables, functions, constants, types, or macros, > in the namespace MPI." And change-log entry Sections 2.6.2 and 2.6.3 on pages 18 and 19, and MPI-2.2, Section 2.6.2 on page 17, lines 41-42, Section 2.6.3 on page 18, lines 15-16, and Section 2.6.4 on page 18, lines 40-41. This is an MPI-2 erratum: The scope for the reserved prefix MPI_ and the C++ namespace MPI was extended to any name. ------------------------------- Best regards Rolf ----- Original Message ----- > On Sun, 26 Aug 2012, Bronis R. de Supinski wrote: > > I think we should defer the issue to MPI Next. > > On Sun, 26 Aug 2012, Rolf Rabenseifner wrote: > > > Hello Bronis, Kathryn, Dave, > > > > Do you agree with Martin's opinion and his suggested addition > > for the tools chapter? ... -- 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-forum] Reserved MPI_ prefix & namespace in C and Fortran
by Bronis R. de Supinski 26 Aug '12

26 Aug '12

I think we should defer the issue to MPI Next. On Sun, 26 Aug 2012, Rolf Rabenseifner wrote: > Hello Bronis, Kathryn, Dave, > > Do you agree with Martin's opinion and his suggested addition > for the tools chapter? > > Martin's proposal > ---------------------- >>>>>> Add a new sentence after MPI-2.2, Chapter 14 "Profiling", >>>>>> Sect. 14.2 "Discussion", page 454, line 17, >>>>>> respectively, after MPI-3.0 Draft 2, Section 14.2 "Profiling", >>>>>> Sect. 14.2.2 "Discussion", page 558, line 34/35: > >> "Tools providing functionality by intercepting routines through the >> MPI Profiling Interface must ensure that the semantics implemented by >> the intercepting functions fully conforms to the specification of the >> intercepted call." > ----------------------- > > > I believe, it is the better way to solve the inconsistency > reported by Bronis, really better than my wording > (I added the "semantics" to be more correct): > >>>>>> Typically, the profiling interface is used by implementing >>>>>> a new application or profiling function that has the same > name and semantics >>>>>> as an MPI routine and internally calls the corresponding >>>>>> PMPI routine; this is an exception to the name prefix >>>>>> reservation rules in Sections 2.6.2 and 2.6.3 on pages 18 and 19. > > But I really prefer Martin's approach. > > With Martin's approach, Bronis' problem >>>>>>> It is simply wrong. The standard is not consistent. >>>>>>> >>>>>>> Specifically, when one uses the MPI profiling interface, the >>>>>>> mechanism is precisely to declare functions that begin with >>>>>>> MPI_. > is solved, without restricting the reservation rules in Terms. > > Okay, Bronis, Kathryn, and Dave, do you want to go this direction? > I would include it into this erratum. > > Best regards > Rolf > > > > ----- Original Message ----- >> From: "Martin Schulz" <schulzm(a)llnl.gov> >> To: "Bronis R. de Supinski" <bronis(a)llnl.gov> >> Cc: "Rolf Rabenseifner" <rabenseifner(a)hlrs.de>, "Dave Goodell" <goodell(a)mcs.anl.gov>, "Kathryn Mohror" >> <mohror1(a)llnl.gov>, "Main MPI Forum mailing list" <mpi-forum(a)lists.mpi-forum.org> >> Sent: Sunday, August 26, 2012 7:48:07 AM >> Subject: Re: [Mpi-forum] Reserved MPI_ prefix & namespace in C and Fortran >> Hi Rolf, Bronis, >> >> I personally think that we don't need or should have such a >> clarification (neither in 2 nor 14) - the way I have always seen it, >> tools that use the PMPI interface, and hence provide MPI_ functions, >> effectively "become" the MPI implementation/library from the view >> point of the application (irrespective of the fact that they use an >> MPI library themselves via the PMPI calls). Hence, they provide >> standard conform MPI functions and can certainly use the name space >> (as any other code that we happen to call MPI library). They can't >> change the meaning of the calls (or the applications will break) and >> can't offer additional calls starting with MPI_, just as any other MPI >> implementation. >> >> If people see this differently and do want to add something, we need >> to be very careful, though, how we specify it: >> >>>>>> Typically, the profiling interface is used by implementing >>>>>> a new application or profiling function that has the same >>>>>> name as an MPI routine and internally calls the corresponding >> >> This is not correct - PMPI tools no longer provide a routine with the >> same name - they need to provide up to 7 (was that the number?) >> routines with different names and for new Fortran interface, the >> functions no longer have the same name. >> >>>>>> PMPI routine; this is an exception to the name prefix >> >> I know that the sentence started with typically, but this is only true >> for classic profilers or tracers - many other tools no longer call the >> corresponding PMPI routine - they can call many other routines (e.g., >> dissolve collectives, duplicate messages for piggybacking, enforce >> ordering by adding synchronization, or even swallow MPI calls, e.g., >> for FT recovery protocols or for MPI process cloning tools). >> >>>>>> reservation rules in Sections 2.6.2 and 2.6.3 on pages 18 and >>>>>> 19. >> >> Additionally, this definition and view of the tools now only allows >> tools to replace MPI function calls - there are tools, like MPI >> Adaptor, that do much more and, e.g., replace types - they provide a >> new header file, but the interception may still run through PMPI. >> >> Overall, the usage of PMPI has gone way beyond what the original >> authors in MPI-1 had in mind and we shouldn't fix ourselves to that, >> since this would cause problems. >> >> Therefore, if we wanted to add something for clarification, I would >> suggest an advice (not sure to whom) in chapter 14.1 saying that >> "Tools providing functionality by intercepting routines through the >> MPI Profiling Interface must ensure that the semantics implemented by >> the intercepting functions fully conforms to the specification of the >> intercepted call." >> >> Martin >> >> >> On Aug 25, 2012, at 9:29 AM, Bronis R. de Supinski wrote: >> >>> >>> Martin, Dave and Kathryn: >>> >>> Do you agree with Rolf's suggested addition for the >>> tools chapter? I am ambivalent but will make the >>> change and send it to Rich if you do. >>> >>> Bronis >>> >>> >>> On Sat, 25 Aug 2012, Rolf Rabenseifner wrote: >>> >>>> Okay, we should refer in both directions: >>>> >>>> Add additional the sentence after MPI-3.0 Draft 2, page 19 line 16 >>>> (MPI-2.2 p18:17): >>>> >>>> The MPI_ prefix reservation is relaxed when the profiling >>>> interface is used, see Section 14.2.2 on page 558 for details. >>>> >>>> Same sentence for Fortran after MPI-3.0 Draft 2 p18:42 / MPI-2.2 >>>> p17:44. >>>> For C++, the following is needed after MPI-2.2 p18:41: >>>> >>>> The MPI namespace reservation is relaxed when the profiling >>>> interface is used, see Section 14.2.2 on page 558 for details. >>>> >>>> And: >>>>>> Add a new sentence after MPI-2.2, Chapter 14 "Profiling", >>>>>> Sect. 14.2 "Discussion", page 454, line 17, >>>>>> respectively, after MPI-3.0 Draft 2, Section 14.2 "Profiling", >>>>>> Sect. 14.2.2 "Discussion", page 558, line 34/35: >>>>>> >>>>>> Typically, the profiling interface is used by implementing >>>>>> a new application or profiling function that has the same >>>>>> name as an MPI routine and internally calls the corresponding >>>>>> PMPI routine; this is an exception to the name prefix >>>>>> reservation rules in Sections 2.6.2 and 2.6.3 on pages 18 and >>>>>> 19. >>>>>> >>>> >>>> Good so? >>>> >>>> Rolf >>>> >>>> ----- Original Message ----- >>>>> From: "Bronis R. de Supinski" <bronis(a)llnl.gov> >>>>> To: "Rolf Rabenseifner" <rabenseifner(a)hlrs.de> >>>>> Cc: "Martin Schulz" <schulzm(a)llnl.gov>, "Dave Goodell" >>>>> <goodell(a)mcs.anl.gov>, "Kathryn Mohror" <mohror1(a)llnl.gov>, >>>>> "Main MPI Forum mailing list" <mpi-forum(a)lists.mpi-forum.org> >>>>> Sent: Saturday, August 25, 2012 4:39:53 PM >>>>> Subject: Re: [Mpi-forum] Reserved MPI_ prefix & namespace in C and >>>>> Fortran >>>>> I agree with Bill that the right solution is a forward >>>>> reference at the point the restriction is defined. It >>>>> will be lost if we bury it in the tools chapter. >>>>> >>>>> On Sat, 25 Aug 2012, Rolf Rabenseifner wrote: >>>>> >>>>>> Bronis, Martin, Dave, Kathryn, and all tools people, >>>>>> >>>>>> Yes, we should also solve this 2nd inconsistency about >>>>>> defining MPI_Xxxx with real MPI-names when writing a tools layer, >>>>>> which is inconsistent with the prefix reservation in Sect. >>>>>> 2.6.2-2.6.4 >>>>>> with the original wording and also with the new wording below. >>>>>> >>>>>> Here, I would propose to relax the prefix reservation defined in >>>>>> Sections 2.6.2 - 2.6.4 by a sentence in the tools chapter >>>>>> that refers to Sect. 2.6.2-2.6.4. >>>>>> >>>>>> Proposed solution (please take it a s a first draft): >>>>>> >>>>>> Add a new sentence after MPI-2.2, Chapter 14 "Profiling", >>>>>> Sect. 14.2 "Discussion", page 454, line 17, >>>>>> respectively, after MPI-3.0 Draft 2, Section 14.2 "Profiling", >>>>>> Sect. 14.2.2 "Discussion", page 558, line 34/35: >>>>>> >>>>>> Typically, the profiling interface is used by implementing >>>>>> a new application or profiling function that has the same >>>>>> name as an MPI routine and internally calls the corresponding >>>>>> PMPI routine; this is an exception to the name prefix >>>>>> reservation rules in Sections 2.6.2 and 2.6.3 on pages 18 and >>>>>> 19. >>>>>> >>>>>> Because this is specific to the profiling layer, I would not >>>>>> stress the wording in the Terms chapter. The right position >>>>>> is really the tools chapter. >>>>>> >>>>>> You, as the tools group may find a better wording and fine >>>>>> grained >>>>>> position of this sentence. Important is, that this sentence >>>>>> only solves the existing inconsistency, because this is the scope >>>>>> of this erratum. >>>>>> >>>>>> Okay? Better proposals? Comments? >>>>>> >>>>>> ----------------------------------- >>>>>> Here again the latest version of the text in Sections 2.6.2 - >>>>>> 2.6.4: >>>>>> >>>>>> C: >>>>>>> "Programs must not declare >>>>>> names (identifiers), e.g., for variables, functions, >>>>>> constants, types, or macros, >>>>>>> beginning with the prefix MPI_." >>>>>> >>>>>> Fortran: >>>>>>> "Programs must not declare >>>>>> names, e.g., for variables, subroutines, functions, >>>>>> parameters, derived types, abstract interfaces, or modules, >>>>>>> beginning with the prefix MPI_. >>>>>> >>>>>> and for Fortran also "subroutines and functions" instead of >>>>>> only "functions" in the sentence about PMPI_. >>>>>> >>>>>> C++ >>>>>>> "Programs must not declare >>>>>> names (identifiers), e.g., for variables, functions, >>>>>> constants, types, or macros, >>>>>>> in the namespace MPI." >>>>>> ----------------------------------- >>>>>> >>>>>> Best regards >>>>>> Rolf >>>>>> >>>>>> ----- Original Message ----- >>>>>>> From: "Bronis R. de Supinski" <bronis(a)llnl.gov> >>>>>>> To: "Main MPI Forum mailing list" >>>>>>> <mpi-forum(a)lists.mpi-forum.org> >>>>>>> Sent: Saturday, August 25, 2012 2:34:38 PM >>>>>>> Subject: Re: [Mpi-forum] Reserved MPI_ prefix & namespace in C >>>>>>> and Fortran >>>>>>> >>>>>>> So, while we are debating whether the wording is sufficient, >>>>>>> we are overlooking a far more important error in the >>>>>>> restriction. >>>>>>> It is simply wrong. The standard is not consistent. >>>>>>> >>>>>>> Specifically, when one uses the MPI profiling interface, the >>>>>>> mechanism is precisely to declare functions that begin with >>>>>>> MPI_. So the intent of the standard is that we are supposed >>>>>>> to violate that restriction. This issue has nagged at me in >>>>>>> the past but I have simply ignored it. However, I would oppose >>>>>>> increasing the scope of the restriction without fixing the >>>>>>> real inconsistency. >>>>>>> _______________________________________________ >>>>>>> mpi-forum mailing list >>>>>>> mpi-forum(a)lists.mpi-forum.org >>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>>>>> >>>>>> -- >>>>>> 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) >>>>>> >>>> >>>> -- >>>> 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) >>>> >> >> ________________________________________________________________________ >> Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulzm >> CASC @ Lawrence Livermore National Laboratory, Livermore, USA > > -- > 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-forum] Reserved MPI_ prefix & namespace in C and Fortran
by N.M. Maclaren 26 Aug '12

26 Aug '12

On Aug 26 2012, Rolf Rabenseifner wrote: > >Hello Bronis, Kathryn, Dave, > >Do you agree with Martin's opinion and his suggested addition >for the tools chapter? > >Martin's proposal >---------------------- >> >>>> Add a new sentence after MPI-2.2, Chapter 14 "Profiling", >> >>>> Sect. 14.2 "Discussion", page 454, line 17, >> >>>> respectively, after MPI-3.0 Draft 2, Section 14.2 "Profiling", >> >>>> Sect. 14.2.2 "Discussion", page 558, line 34/35: > >> "Tools providing functionality by intercepting routines through the >> MPI Profiling Interface must ensure that the semantics implemented by >> the intercepting functions fully conforms to the specification of the >> intercepted call." >----------------------- While it's obviously the intent, spelling it out would help when trying to get a particularly bone-headed developer to fix his code. That relates to one of William Gropp's points. The critical aspect for normal use and implementation is that the intent is both crystal clear and precise enough to allow of only one interpretation. Where legalese is needed is for arguing with a developer (whether vendor, user or other) who is trying to find some excuse for not fixing a bug. In my experience, this aspect rarely triggers that situation, so all that is critically needed is that the intent be made unambiguous. The original proposal looks pretty solid in that respect, and this does not conflict. Whether it's needed is a matter of opinion. Regards, Nick Maclaren.

1 0

Re: [Mpi-forum] Reserved MPI_ prefix & namespace in C and Fortran
by Rolf Rabenseifner 26 Aug '12

26 Aug '12

Hello Bronis, Kathryn, Dave, Do you agree with Martin's opinion and his suggested addition for the tools chapter? Martin's proposal ---------------------- > >>>> Add a new sentence after MPI-2.2, Chapter 14 "Profiling", > >>>> Sect. 14.2 "Discussion", page 454, line 17, > >>>> respectively, after MPI-3.0 Draft 2, Section 14.2 "Profiling", > >>>> Sect. 14.2.2 "Discussion", page 558, line 34/35: > "Tools providing functionality by intercepting routines through the > MPI Profiling Interface must ensure that the semantics implemented by > the intercepting functions fully conforms to the specification of the > intercepted call." ----------------------- I believe, it is the better way to solve the inconsistency reported by Bronis, really better than my wording (I added the "semantics" to be more correct): > >>>> Typically, the profiling interface is used by implementing > >>>> a new application or profiling function that has the same name and semantics > >>>> as an MPI routine and internally calls the corresponding > >>>> PMPI routine; this is an exception to the name prefix > >>>> reservation rules in Sections 2.6.2 and 2.6.3 on pages 18 and 19. But I really prefer Martin's approach. With Martin's approach, Bronis' problem > >>>>> It is simply wrong. The standard is not consistent. > >>>>> > >>>>> Specifically, when one uses the MPI profiling interface, the > >>>>> mechanism is precisely to declare functions that begin with > >>>>> MPI_. is solved, without restricting the reservation rules in Terms. Okay, Bronis, Kathryn, and Dave, do you want to go this direction? I would include it into this erratum. Best regards Rolf ----- Original Message ----- > From: "Martin Schulz" <schulzm(a)llnl.gov> > To: "Bronis R. de Supinski" <bronis(a)llnl.gov> > Cc: "Rolf Rabenseifner" <rabenseifner(a)hlrs.de>, "Dave Goodell" <goodell(a)mcs.anl.gov>, "Kathryn Mohror" > <mohror1(a)llnl.gov>, "Main MPI Forum mailing list" <mpi-forum(a)lists.mpi-forum.org> > Sent: Sunday, August 26, 2012 7:48:07 AM > Subject: Re: [Mpi-forum] Reserved MPI_ prefix & namespace in C and Fortran > Hi Rolf, Bronis, > > I personally think that we don't need or should have such a > clarification (neither in 2 nor 14) - the way I have always seen it, > tools that use the PMPI interface, and hence provide MPI_ functions, > effectively "become" the MPI implementation/library from the view > point of the application (irrespective of the fact that they use an > MPI library themselves via the PMPI calls). Hence, they provide > standard conform MPI functions and can certainly use the name space > (as any other code that we happen to call MPI library). They can't > change the meaning of the calls (or the applications will break) and > can't offer additional calls starting with MPI_, just as any other MPI > implementation. > > If people see this differently and do want to add something, we need > to be very careful, though, how we specify it: > > >>>> Typically, the profiling interface is used by implementing > >>>> a new application or profiling function that has the same > >>>> name as an MPI routine and internally calls the corresponding > > This is not correct - PMPI tools no longer provide a routine with the > same name - they need to provide up to 7 (was that the number?) > routines with different names and for new Fortran interface, the > functions no longer have the same name. > > >>>> PMPI routine; this is an exception to the name prefix > > I know that the sentence started with typically, but this is only true > for classic profilers or tracers - many other tools no longer call the > corresponding PMPI routine - they can call many other routines (e.g., > dissolve collectives, duplicate messages for piggybacking, enforce > ordering by adding synchronization, or even swallow MPI calls, e.g., > for FT recovery protocols or for MPI process cloning tools). > > >>>> reservation rules in Sections 2.6.2 and 2.6.3 on pages 18 and > >>>> 19. > > Additionally, this definition and view of the tools now only allows > tools to replace MPI function calls - there are tools, like MPI > Adaptor, that do much more and, e.g., replace types - they provide a > new header file, but the interception may still run through PMPI. > > Overall, the usage of PMPI has gone way beyond what the original > authors in MPI-1 had in mind and we shouldn't fix ourselves to that, > since this would cause problems. > > Therefore, if we wanted to add something for clarification, I would > suggest an advice (not sure to whom) in chapter 14.1 saying that > "Tools providing functionality by intercepting routines through the > MPI Profiling Interface must ensure that the semantics implemented by > the intercepting functions fully conforms to the specification of the > intercepted call." > > Martin > > > On Aug 25, 2012, at 9:29 AM, Bronis R. de Supinski wrote: > > > > > Martin, Dave and Kathryn: > > > > Do you agree with Rolf's suggested addition for the > > tools chapter? I am ambivalent but will make the > > change and send it to Rich if you do. > > > > Bronis > > > > > > On Sat, 25 Aug 2012, Rolf Rabenseifner wrote: > > > >> Okay, we should refer in both directions: > >> > >> Add additional the sentence after MPI-3.0 Draft 2, page 19 line 16 > >> (MPI-2.2 p18:17): > >> > >> The MPI_ prefix reservation is relaxed when the profiling > >> interface is used, see Section 14.2.2 on page 558 for details. > >> > >> Same sentence for Fortran after MPI-3.0 Draft 2 p18:42 / MPI-2.2 > >> p17:44. > >> For C++, the following is needed after MPI-2.2 p18:41: > >> > >> The MPI namespace reservation is relaxed when the profiling > >> interface is used, see Section 14.2.2 on page 558 for details. > >> > >> And: > >>>> Add a new sentence after MPI-2.2, Chapter 14 "Profiling", > >>>> Sect. 14.2 "Discussion", page 454, line 17, > >>>> respectively, after MPI-3.0 Draft 2, Section 14.2 "Profiling", > >>>> Sect. 14.2.2 "Discussion", page 558, line 34/35: > >>>> > >>>> Typically, the profiling interface is used by implementing > >>>> a new application or profiling function that has the same > >>>> name as an MPI routine and internally calls the corresponding > >>>> PMPI routine; this is an exception to the name prefix > >>>> reservation rules in Sections 2.6.2 and 2.6.3 on pages 18 and > >>>> 19. > >>>> > >> > >> Good so? > >> > >> Rolf > >> > >> ----- Original Message ----- > >>> From: "Bronis R. de Supinski" <bronis(a)llnl.gov> > >>> To: "Rolf Rabenseifner" <rabenseifner(a)hlrs.de> > >>> Cc: "Martin Schulz" <schulzm(a)llnl.gov>, "Dave Goodell" > >>> <goodell(a)mcs.anl.gov>, "Kathryn Mohror" <mohror1(a)llnl.gov>, > >>> "Main MPI Forum mailing list" <mpi-forum(a)lists.mpi-forum.org> > >>> Sent: Saturday, August 25, 2012 4:39:53 PM > >>> Subject: Re: [Mpi-forum] Reserved MPI_ prefix & namespace in C and > >>> Fortran > >>> I agree with Bill that the right solution is a forward > >>> reference at the point the restriction is defined. It > >>> will be lost if we bury it in the tools chapter. > >>> > >>> On Sat, 25 Aug 2012, Rolf Rabenseifner wrote: > >>> > >>>> Bronis, Martin, Dave, Kathryn, and all tools people, > >>>> > >>>> Yes, we should also solve this 2nd inconsistency about > >>>> defining MPI_Xxxx with real MPI-names when writing a tools layer, > >>>> which is inconsistent with the prefix reservation in Sect. > >>>> 2.6.2-2.6.4 > >>>> with the original wording and also with the new wording below. > >>>> > >>>> Here, I would propose to relax the prefix reservation defined in > >>>> Sections 2.6.2 - 2.6.4 by a sentence in the tools chapter > >>>> that refers to Sect. 2.6.2-2.6.4. > >>>> > >>>> Proposed solution (please take it a s a first draft): > >>>> > >>>> Add a new sentence after MPI-2.2, Chapter 14 "Profiling", > >>>> Sect. 14.2 "Discussion", page 454, line 17, > >>>> respectively, after MPI-3.0 Draft 2, Section 14.2 "Profiling", > >>>> Sect. 14.2.2 "Discussion", page 558, line 34/35: > >>>> > >>>> Typically, the profiling interface is used by implementing > >>>> a new application or profiling function that has the same > >>>> name as an MPI routine and internally calls the corresponding > >>>> PMPI routine; this is an exception to the name prefix > >>>> reservation rules in Sections 2.6.2 and 2.6.3 on pages 18 and > >>>> 19. > >>>> > >>>> Because this is specific to the profiling layer, I would not > >>>> stress the wording in the Terms chapter. The right position > >>>> is really the tools chapter. > >>>> > >>>> You, as the tools group may find a better wording and fine > >>>> grained > >>>> position of this sentence. Important is, that this sentence > >>>> only solves the existing inconsistency, because this is the scope > >>>> of this erratum. > >>>> > >>>> Okay? Better proposals? Comments? > >>>> > >>>> ----------------------------------- > >>>> Here again the latest version of the text in Sections 2.6.2 - > >>>> 2.6.4: > >>>> > >>>> C: > >>>>> "Programs must not declare > >>>> names (identifiers), e.g., for variables, functions, > >>>> constants, types, or macros, > >>>>> beginning with the prefix MPI_." > >>>> > >>>> Fortran: > >>>>> "Programs must not declare > >>>> names, e.g., for variables, subroutines, functions, > >>>> parameters, derived types, abstract interfaces, or modules, > >>>>> beginning with the prefix MPI_. > >>>> > >>>> and for Fortran also "subroutines and functions" instead of > >>>> only "functions" in the sentence about PMPI_. > >>>> > >>>> C++ > >>>>> "Programs must not declare > >>>> names (identifiers), e.g., for variables, functions, > >>>> constants, types, or macros, > >>>>> in the namespace MPI." > >>>> ----------------------------------- > >>>> > >>>> Best regards > >>>> Rolf > >>>> > >>>> ----- Original Message ----- > >>>>> From: "Bronis R. de Supinski" <bronis(a)llnl.gov> > >>>>> To: "Main MPI Forum mailing list" > >>>>> <mpi-forum(a)lists.mpi-forum.org> > >>>>> Sent: Saturday, August 25, 2012 2:34:38 PM > >>>>> Subject: Re: [Mpi-forum] Reserved MPI_ prefix & namespace in C > >>>>> and Fortran > >>>>> > >>>>> So, while we are debating whether the wording is sufficient, > >>>>> we are overlooking a far more important error in the > >>>>> restriction. > >>>>> It is simply wrong. The standard is not consistent. > >>>>> > >>>>> Specifically, when one uses the MPI profiling interface, the > >>>>> mechanism is precisely to declare functions that begin with > >>>>> MPI_. So the intent of the standard is that we are supposed > >>>>> to violate that restriction. This issue has nagged at me in > >>>>> the past but I have simply ignored it. However, I would oppose > >>>>> increasing the scope of the restriction without fixing the > >>>>> real inconsistency. > >>>>> _______________________________________________ > >>>>> mpi-forum mailing list > >>>>> mpi-forum(a)lists.mpi-forum.org > >>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > >>>> > >>>> -- > >>>> 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) > >>>> > >> > >> -- > >> 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) > >> > > ________________________________________________________________________ > Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulzm > CASC @ Lawrence Livermore National Laboratory, Livermore, USA -- 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-forum] Reserved MPI_ prefix & namespace in C and Fortran
by Schulz, Martin 26 Aug '12

26 Aug '12

Hi Rolf, Bronis, I personally think that we don't need or should have such a clarification (neither in 2 nor 14) - the way I have always seen it, tools that use the PMPI interface, and hence provide MPI_ functions, effectively "become" the MPI implementation/library from the view point of the application (irrespective of the fact that they use an MPI library themselves via the PMPI calls). Hence, they provide standard conform MPI functions and can certainly use the name space (as any other code that we happen to call MPI library). They can't change the meaning of the calls (or the applications will break) and can't offer additional calls starting with MPI_, just as any other MPI implementation. If people see this differently and do want to add something, we need to be very careful, though, how we specify it: >>>> Typically, the profiling interface is used by implementing >>>> a new application or profiling function that has the same >>>> name as an MPI routine and internally calls the corresponding This is not correct - PMPI tools no longer provide a routine with the same name - they need to provide up to 7 (was that the number?) routines with different names and for new Fortran interface, the functions no longer have the same name. >>>> PMPI routine; this is an exception to the name prefix I know that the sentence started with typically, but this is only true for classic profilers or tracers - many other tools no longer call the corresponding PMPI routine - they can call many other routines (e.g., dissolve collectives, duplicate messages for piggybacking, enforce ordering by adding synchronization, or even swallow MPI calls, e.g., for FT recovery protocols or for MPI process cloning tools). >>>> reservation rules in Sections 2.6.2 and 2.6.3 on pages 18 and 19. Additionally, this definition and view of the tools now only allows tools to replace MPI function calls - there are tools, like MPI Adaptor, that do much more and, e.g., replace types - they provide a new header file, but the interception may still run through PMPI. Overall, the usage of PMPI has gone way beyond what the original authors in MPI-1 had in mind and we shouldn't fix ourselves to that, since this would cause problems. Therefore, if we wanted to add something for clarification, I would suggest an advice (not sure to whom) in chapter 14.1 saying that "Tools providing functionality by intercepting routines through the MPI Profiling Interface must ensure that the semantics implemented by the intercepting functions fully conforms to the specification of the intercepted call." Martin On Aug 25, 2012, at 9:29 AM, Bronis R. de Supinski wrote: > > Martin, Dave and Kathryn: > > Do you agree with Rolf's suggested addition for the > tools chapter? I am ambivalent but will make the > change and send it to Rich if you do. > > Bronis > > > On Sat, 25 Aug 2012, Rolf Rabenseifner wrote: > >> Okay, we should refer in both directions: >> >> Add additional the sentence after MPI-3.0 Draft 2, page 19 line 16 >> (MPI-2.2 p18:17): >> >> The MPI_ prefix reservation is relaxed when the profiling >> interface is used, see Section 14.2.2 on page 558 for details. >> >> Same sentence for Fortran after MPI-3.0 Draft 2 p18:42 / MPI-2.2 p17:44. >> For C++, the following is needed after MPI-2.2 p18:41: >> >> The MPI namespace reservation is relaxed when the profiling >> interface is used, see Section 14.2.2 on page 558 for details. >> >> And: >>>> Add a new sentence after MPI-2.2, Chapter 14 "Profiling", >>>> Sect. 14.2 "Discussion", page 454, line 17, >>>> respectively, after MPI-3.0 Draft 2, Section 14.2 "Profiling", >>>> Sect. 14.2.2 "Discussion", page 558, line 34/35: >>>> >>>> Typically, the profiling interface is used by implementing >>>> a new application or profiling function that has the same >>>> name as an MPI routine and internally calls the corresponding >>>> PMPI routine; this is an exception to the name prefix >>>> reservation rules in Sections 2.6.2 and 2.6.3 on pages 18 and 19. >>>> >> >> Good so? >> >> Rolf >> >> ----- Original Message ----- >>> From: "Bronis R. de Supinski" <bronis(a)llnl.gov> >>> To: "Rolf Rabenseifner" <rabenseifner(a)hlrs.de> >>> Cc: "Martin Schulz" <schulzm(a)llnl.gov>, "Dave Goodell" <goodell(a)mcs.anl.gov>, "Kathryn Mohror" <mohror1(a)llnl.gov>, >>> "Main MPI Forum mailing list" <mpi-forum(a)lists.mpi-forum.org> >>> Sent: Saturday, August 25, 2012 4:39:53 PM >>> Subject: Re: [Mpi-forum] Reserved MPI_ prefix & namespace in C and Fortran >>> I agree with Bill that the right solution is a forward >>> reference at the point the restriction is defined. It >>> will be lost if we bury it in the tools chapter. >>> >>> On Sat, 25 Aug 2012, Rolf Rabenseifner wrote: >>> >>>> Bronis, Martin, Dave, Kathryn, and all tools people, >>>> >>>> Yes, we should also solve this 2nd inconsistency about >>>> defining MPI_Xxxx with real MPI-names when writing a tools layer, >>>> which is inconsistent with the prefix reservation in Sect. >>>> 2.6.2-2.6.4 >>>> with the original wording and also with the new wording below. >>>> >>>> Here, I would propose to relax the prefix reservation defined in >>>> Sections 2.6.2 - 2.6.4 by a sentence in the tools chapter >>>> that refers to Sect. 2.6.2-2.6.4. >>>> >>>> Proposed solution (please take it a s a first draft): >>>> >>>> Add a new sentence after MPI-2.2, Chapter 14 "Profiling", >>>> Sect. 14.2 "Discussion", page 454, line 17, >>>> respectively, after MPI-3.0 Draft 2, Section 14.2 "Profiling", >>>> Sect. 14.2.2 "Discussion", page 558, line 34/35: >>>> >>>> Typically, the profiling interface is used by implementing >>>> a new application or profiling function that has the same >>>> name as an MPI routine and internally calls the corresponding >>>> PMPI routine; this is an exception to the name prefix >>>> reservation rules in Sections 2.6.2 and 2.6.3 on pages 18 and 19. >>>> >>>> Because this is specific to the profiling layer, I would not >>>> stress the wording in the Terms chapter. The right position >>>> is really the tools chapter. >>>> >>>> You, as the tools group may find a better wording and fine grained >>>> position of this sentence. Important is, that this sentence >>>> only solves the existing inconsistency, because this is the scope >>>> of this erratum. >>>> >>>> Okay? Better proposals? Comments? >>>> >>>> ----------------------------------- >>>> Here again the latest version of the text in Sections 2.6.2 - 2.6.4: >>>> >>>> C: >>>>> "Programs must not declare >>>> names (identifiers), e.g., for variables, functions, >>>> constants, types, or macros, >>>>> beginning with the prefix MPI_." >>>> >>>> Fortran: >>>>> "Programs must not declare >>>> names, e.g., for variables, subroutines, functions, >>>> parameters, derived types, abstract interfaces, or modules, >>>>> beginning with the prefix MPI_. >>>> >>>> and for Fortran also "subroutines and functions" instead of >>>> only "functions" in the sentence about PMPI_. >>>> >>>> C++ >>>>> "Programs must not declare >>>> names (identifiers), e.g., for variables, functions, >>>> constants, types, or macros, >>>>> in the namespace MPI." >>>> ----------------------------------- >>>> >>>> Best regards >>>> Rolf >>>> >>>> ----- Original Message ----- >>>>> From: "Bronis R. de Supinski" <bronis(a)llnl.gov> >>>>> To: "Main MPI Forum mailing list" <mpi-forum(a)lists.mpi-forum.org> >>>>> Sent: Saturday, August 25, 2012 2:34:38 PM >>>>> Subject: Re: [Mpi-forum] Reserved MPI_ prefix & namespace in C and >>>>> Fortran >>>>> So, while we are debating whether the wording is sufficient, >>>>> we are overlooking a far more important error in the restriction. >>>>> It is simply wrong. The standard is not consistent. >>>>> >>>>> Specifically, when one uses the MPI profiling interface, the >>>>> mechanism is precisely to declare functions that begin with >>>>> MPI_. So the intent of the standard is that we are supposed >>>>> to violate that restriction. This issue has nagged at me in >>>>> the past but I have simply ignored it. However, I would oppose >>>>> increasing the scope of the restriction without fixing the >>>>> real inconsistency. >>>>> _______________________________________________ >>>>> mpi-forum mailing list >>>>> mpi-forum(a)lists.mpi-forum.org >>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>>> >>>> -- >>>> 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) >>>> >> >> -- >> 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) >> ________________________________________________________________________ Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulzm CASC @ Lawrence Livermore National Laboratory, Livermore, USA

1 0

Re: [Mpi-forum] Reserved MPI_ prefix & namespace in C and Fortran
by Kathryn Mohror 25 Aug '12

25 Aug '12

Hi Bronis, The suggested change seems fine to me. Kathryn On 8/25/2012 9:29 AM, Bronis R. de Supinski wrote: > > Martin, Dave and Kathryn: > > Do you agree with Rolf's suggested addition for the > tools chapter? I am ambivalent but will make the > change and send it to Rich if you do. > > Bronis > > > On Sat, 25 Aug 2012, Rolf Rabenseifner wrote: > >> Okay, we should refer in both directions: >> >> Add additional the sentence after MPI-3.0 Draft 2, page 19 line 16 >> (MPI-2.2 p18:17): >> >> The MPI_ prefix reservation is relaxed when the profiling >> interface is used, see Section 14.2.2 on page 558 for details. >> >> Same sentence for Fortran after MPI-3.0 Draft 2 p18:42 / MPI-2.2 p17:44. >> For C++, the following is needed after MPI-2.2 p18:41: >> >> The MPI namespace reservation is relaxed when the profiling >> interface is used, see Section 14.2.2 on page 558 for details. >> >> And: >>>> Add a new sentence after MPI-2.2, Chapter 14 "Profiling", >>>> Sect. 14.2 "Discussion", page 454, line 17, >>>> respectively, after MPI-3.0 Draft 2, Section 14.2 "Profiling", >>>> Sect. 14.2.2 "Discussion", page 558, line 34/35: >>>> >>>> Typically, the profiling interface is used by implementing >>>> a new application or profiling function that has the same >>>> name as an MPI routine and internally calls the corresponding >>>> PMPI routine; this is an exception to the name prefix >>>> reservation rules in Sections 2.6.2 and 2.6.3 on pages 18 and 19. >>>> >> >> Good so? >> >> Rolf >> >> ----- Original Message ----- >>> From: "Bronis R. de Supinski" <bronis(a)llnl.gov> >>> To: "Rolf Rabenseifner" <rabenseifner(a)hlrs.de> >>> Cc: "Martin Schulz" <schulzm(a)llnl.gov>, "Dave Goodell" <goodell(a)mcs.anl.gov>, "Kathryn Mohror" <mohror1(a)llnl.gov>, >>> "Main MPI Forum mailing list" <mpi-forum(a)lists.mpi-forum.org> >>> Sent: Saturday, August 25, 2012 4:39:53 PM >>> Subject: Re: [Mpi-forum] Reserved MPI_ prefix & namespace in C and Fortran >>> I agree with Bill that the right solution is a forward >>> reference at the point the restriction is defined. It >>> will be lost if we bury it in the tools chapter. >>> >>> On Sat, 25 Aug 2012, Rolf Rabenseifner wrote: >>> >>>> Bronis, Martin, Dave, Kathryn, and all tools people, >>>> >>>> Yes, we should also solve this 2nd inconsistency about >>>> defining MPI_Xxxx with real MPI-names when writing a tools layer, >>>> which is inconsistent with the prefix reservation in Sect. >>>> 2.6.2-2.6.4 >>>> with the original wording and also with the new wording below. >>>> >>>> Here, I would propose to relax the prefix reservation defined in >>>> Sections 2.6.2 - 2.6.4 by a sentence in the tools chapter >>>> that refers to Sect. 2.6.2-2.6.4. >>>> >>>> Proposed solution (please take it a s a first draft): >>>> >>>> Add a new sentence after MPI-2.2, Chapter 14 "Profiling", >>>> Sect. 14.2 "Discussion", page 454, line 17, >>>> respectively, after MPI-3.0 Draft 2, Section 14.2 "Profiling", >>>> Sect. 14.2.2 "Discussion", page 558, line 34/35: >>>> >>>> Typically, the profiling interface is used by implementing >>>> a new application or profiling function that has the same >>>> name as an MPI routine and internally calls the corresponding >>>> PMPI routine; this is an exception to the name prefix >>>> reservation rules in Sections 2.6.2 and 2.6.3 on pages 18 and 19. >>>> >>>> Because this is specific to the profiling layer, I would not >>>> stress the wording in the Terms chapter. The right position >>>> is really the tools chapter. >>>> >>>> You, as the tools group may find a better wording and fine grained >>>> position of this sentence. Important is, that this sentence >>>> only solves the existing inconsistency, because this is the scope >>>> of this erratum. >>>> >>>> Okay? Better proposals? Comments? >>>> >>>> ----------------------------------- >>>> Here again the latest version of the text in Sections 2.6.2 - 2.6.4: >>>> >>>> C: >>>>> "Programs must not declare >>>> names (identifiers), e.g., for variables, functions, >>>> constants, types, or macros, >>>>> beginning with the prefix MPI_." >>>> >>>> Fortran: >>>>> "Programs must not declare >>>> names, e.g., for variables, subroutines, functions, >>>> parameters, derived types, abstract interfaces, or modules, >>>>> beginning with the prefix MPI_. >>>> >>>> and for Fortran also "subroutines and functions" instead of >>>> only "functions" in the sentence about PMPI_. >>>> >>>> C++ >>>>> "Programs must not declare >>>> names (identifiers), e.g., for variables, functions, >>>> constants, types, or macros, >>>>> in the namespace MPI." >>>> ----------------------------------- >>>> >>>> Best regards >>>> Rolf >>>> >>>> ----- Original Message ----- >>>>> From: "Bronis R. de Supinski" <bronis(a)llnl.gov> >>>>> To: "Main MPI Forum mailing list" <mpi-forum(a)lists.mpi-forum.org> >>>>> Sent: Saturday, August 25, 2012 2:34:38 PM >>>>> Subject: Re: [Mpi-forum] Reserved MPI_ prefix & namespace in C and >>>>> Fortran >>>>> So, while we are debating whether the wording is sufficient, >>>>> we are overlooking a far more important error in the restriction. >>>>> It is simply wrong. The standard is not consistent. >>>>> >>>>> Specifically, when one uses the MPI profiling interface, the >>>>> mechanism is precisely to declare functions that begin with >>>>> MPI_. So the intent of the standard is that we are supposed >>>>> to violate that restriction. This issue has nagged at me in >>>>> the past but I have simply ignored it. However, I would oppose >>>>> increasing the scope of the restriction without fixing the >>>>> real inconsistency. >>>>> _______________________________________________ >>>>> mpi-forum mailing list >>>>> mpi-forum(a)lists.mpi-forum.org >>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>>> >>>> -- >>>> 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) >>>> >> >> -- >> 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) >> _____________________________________________________________________ Kathryn Mohror, kathryn(a)llnl.gov, http://people.llnl.gov/mohror1 CASC @ Lawrence Livermore National Laboratory, Livermore, CA, USA

1 0

Re: [Mpi-forum] Reserved MPI_ prefix & namespace in C and Fortran
by Bronis R. de Supinski 25 Aug '12

25 Aug '12

Martin, Dave and Kathryn: Do you agree with Rolf's suggested addition for the tools chapter? I am ambivalent but will make the change and send it to Rich if you do. Bronis On Sat, 25 Aug 2012, Rolf Rabenseifner wrote: > Okay, we should refer in both directions: > > Add additional the sentence after MPI-3.0 Draft 2, page 19 line 16 > (MPI-2.2 p18:17): > > The MPI_ prefix reservation is relaxed when the profiling > interface is used, see Section 14.2.2 on page 558 for details. > > Same sentence for Fortran after MPI-3.0 Draft 2 p18:42 / MPI-2.2 p17:44. > For C++, the following is needed after MPI-2.2 p18:41: > > The MPI namespace reservation is relaxed when the profiling > interface is used, see Section 14.2.2 on page 558 for details. > > And: >>> Add a new sentence after MPI-2.2, Chapter 14 "Profiling", >>> Sect. 14.2 "Discussion", page 454, line 17, >>> respectively, after MPI-3.0 Draft 2, Section 14.2 "Profiling", >>> Sect. 14.2.2 "Discussion", page 558, line 34/35: >>> >>> Typically, the profiling interface is used by implementing >>> a new application or profiling function that has the same >>> name as an MPI routine and internally calls the corresponding >>> PMPI routine; this is an exception to the name prefix >>> reservation rules in Sections 2.6.2 and 2.6.3 on pages 18 and 19. >>> > > Good so? > > Rolf > > ----- Original Message ----- >> From: "Bronis R. de Supinski" <bronis(a)llnl.gov> >> To: "Rolf Rabenseifner" <rabenseifner(a)hlrs.de> >> Cc: "Martin Schulz" <schulzm(a)llnl.gov>, "Dave Goodell" <goodell(a)mcs.anl.gov>, "Kathryn Mohror" <mohror1(a)llnl.gov>, >> "Main MPI Forum mailing list" <mpi-forum(a)lists.mpi-forum.org> >> Sent: Saturday, August 25, 2012 4:39:53 PM >> Subject: Re: [Mpi-forum] Reserved MPI_ prefix & namespace in C and Fortran >> I agree with Bill that the right solution is a forward >> reference at the point the restriction is defined. It >> will be lost if we bury it in the tools chapter. >> >> On Sat, 25 Aug 2012, Rolf Rabenseifner wrote: >> >>> Bronis, Martin, Dave, Kathryn, and all tools people, >>> >>> Yes, we should also solve this 2nd inconsistency about >>> defining MPI_Xxxx with real MPI-names when writing a tools layer, >>> which is inconsistent with the prefix reservation in Sect. >>> 2.6.2-2.6.4 >>> with the original wording and also with the new wording below. >>> >>> Here, I would propose to relax the prefix reservation defined in >>> Sections 2.6.2 - 2.6.4 by a sentence in the tools chapter >>> that refers to Sect. 2.6.2-2.6.4. >>> >>> Proposed solution (please take it a s a first draft): >>> >>> Add a new sentence after MPI-2.2, Chapter 14 "Profiling", >>> Sect. 14.2 "Discussion", page 454, line 17, >>> respectively, after MPI-3.0 Draft 2, Section 14.2 "Profiling", >>> Sect. 14.2.2 "Discussion", page 558, line 34/35: >>> >>> Typically, the profiling interface is used by implementing >>> a new application or profiling function that has the same >>> name as an MPI routine and internally calls the corresponding >>> PMPI routine; this is an exception to the name prefix >>> reservation rules in Sections 2.6.2 and 2.6.3 on pages 18 and 19. >>> >>> Because this is specific to the profiling layer, I would not >>> stress the wording in the Terms chapter. The right position >>> is really the tools chapter. >>> >>> You, as the tools group may find a better wording and fine grained >>> position of this sentence. Important is, that this sentence >>> only solves the existing inconsistency, because this is the scope >>> of this erratum. >>> >>> Okay? Better proposals? Comments? >>> >>> ----------------------------------- >>> Here again the latest version of the text in Sections 2.6.2 - 2.6.4: >>> >>> C: >>>> "Programs must not declare >>> names (identifiers), e.g., for variables, functions, >>> constants, types, or macros, >>>> beginning with the prefix MPI_." >>> >>> Fortran: >>>> "Programs must not declare >>> names, e.g., for variables, subroutines, functions, >>> parameters, derived types, abstract interfaces, or modules, >>>> beginning with the prefix MPI_. >>> >>> and for Fortran also "subroutines and functions" instead of >>> only "functions" in the sentence about PMPI_. >>> >>> C++ >>>> "Programs must not declare >>> names (identifiers), e.g., for variables, functions, >>> constants, types, or macros, >>>> in the namespace MPI." >>> ----------------------------------- >>> >>> Best regards >>> Rolf >>> >>> ----- Original Message ----- >>>> From: "Bronis R. de Supinski" <bronis(a)llnl.gov> >>>> To: "Main MPI Forum mailing list" <mpi-forum(a)lists.mpi-forum.org> >>>> Sent: Saturday, August 25, 2012 2:34:38 PM >>>> Subject: Re: [Mpi-forum] Reserved MPI_ prefix & namespace in C and >>>> Fortran >>>> So, while we are debating whether the wording is sufficient, >>>> we are overlooking a far more important error in the restriction. >>>> It is simply wrong. The standard is not consistent. >>>> >>>> Specifically, when one uses the MPI profiling interface, the >>>> mechanism is precisely to declare functions that begin with >>>> MPI_. So the intent of the standard is that we are supposed >>>> to violate that restriction. This issue has nagged at me in >>>> the past but I have simply ignored it. However, I would oppose >>>> increasing the scope of the restriction without fixing the >>>> real inconsistency. >>>> _______________________________________________ >>>> mpi-forum mailing list >>>> mpi-forum(a)lists.mpi-forum.org >>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>> >>> -- >>> 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) >>> > > -- > 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-forum] Reserved MPI_ prefix & namespace in C and Fortran
by Rolf Rabenseifner 25 Aug '12

25 Aug '12

Okay, we should refer in both directions: Add additional the sentence after MPI-3.0 Draft 2, page 19 line 16 (MPI-2.2 p18:17): The MPI_ prefix reservation is relaxed when the profiling interface is used, see Section 14.2.2 on page 558 for details. Same sentence for Fortran after MPI-3.0 Draft 2 p18:42 / MPI-2.2 p17:44. For C++, the following is needed after MPI-2.2 p18:41: The MPI namespace reservation is relaxed when the profiling interface is used, see Section 14.2.2 on page 558 for details. And: > > Add a new sentence after MPI-2.2, Chapter 14 "Profiling", > > Sect. 14.2 "Discussion", page 454, line 17, > > respectively, after MPI-3.0 Draft 2, Section 14.2 "Profiling", > > Sect. 14.2.2 "Discussion", page 558, line 34/35: > > > > Typically, the profiling interface is used by implementing > > a new application or profiling function that has the same > > name as an MPI routine and internally calls the corresponding > > PMPI routine; this is an exception to the name prefix > > reservation rules in Sections 2.6.2 and 2.6.3 on pages 18 and 19. > > Good so? Rolf ----- Original Message ----- > From: "Bronis R. de Supinski" <bronis(a)llnl.gov> > To: "Rolf Rabenseifner" <rabenseifner(a)hlrs.de> > Cc: "Martin Schulz" <schulzm(a)llnl.gov>, "Dave Goodell" <goodell(a)mcs.anl.gov>, "Kathryn Mohror" <mohror1(a)llnl.gov>, > "Main MPI Forum mailing list" <mpi-forum(a)lists.mpi-forum.org> > Sent: Saturday, August 25, 2012 4:39:53 PM > Subject: Re: [Mpi-forum] Reserved MPI_ prefix & namespace in C and Fortran > I agree with Bill that the right solution is a forward > reference at the point the restriction is defined. It > will be lost if we bury it in the tools chapter. > > On Sat, 25 Aug 2012, Rolf Rabenseifner wrote: > > > Bronis, Martin, Dave, Kathryn, and all tools people, > > > > Yes, we should also solve this 2nd inconsistency about > > defining MPI_Xxxx with real MPI-names when writing a tools layer, > > which is inconsistent with the prefix reservation in Sect. > > 2.6.2-2.6.4 > > with the original wording and also with the new wording below. > > > > Here, I would propose to relax the prefix reservation defined in > > Sections 2.6.2 - 2.6.4 by a sentence in the tools chapter > > that refers to Sect. 2.6.2-2.6.4. > > > > Proposed solution (please take it a s a first draft): > > > > Add a new sentence after MPI-2.2, Chapter 14 "Profiling", > > Sect. 14.2 "Discussion", page 454, line 17, > > respectively, after MPI-3.0 Draft 2, Section 14.2 "Profiling", > > Sect. 14.2.2 "Discussion", page 558, line 34/35: > > > > Typically, the profiling interface is used by implementing > > a new application or profiling function that has the same > > name as an MPI routine and internally calls the corresponding > > PMPI routine; this is an exception to the name prefix > > reservation rules in Sections 2.6.2 and 2.6.3 on pages 18 and 19. > > > > Because this is specific to the profiling layer, I would not > > stress the wording in the Terms chapter. The right position > > is really the tools chapter. > > > > You, as the tools group may find a better wording and fine grained > > position of this sentence. Important is, that this sentence > > only solves the existing inconsistency, because this is the scope > > of this erratum. > > > > Okay? Better proposals? Comments? > > > > ----------------------------------- > > Here again the latest version of the text in Sections 2.6.2 - 2.6.4: > > > > C: > >> "Programs must not declare > > names (identifiers), e.g., for variables, functions, > > constants, types, or macros, > >> beginning with the prefix MPI_." > > > > Fortran: > >> "Programs must not declare > > names, e.g., for variables, subroutines, functions, > > parameters, derived types, abstract interfaces, or modules, > >> beginning with the prefix MPI_. > > > > and for Fortran also "subroutines and functions" instead of > > only "functions" in the sentence about PMPI_. > > > > C++ > >> "Programs must not declare > > names (identifiers), e.g., for variables, functions, > > constants, types, or macros, > >> in the namespace MPI." > > ----------------------------------- > > > > Best regards > > Rolf > > > > ----- Original Message ----- > >> From: "Bronis R. de Supinski" <bronis(a)llnl.gov> > >> To: "Main MPI Forum mailing list" <mpi-forum(a)lists.mpi-forum.org> > >> Sent: Saturday, August 25, 2012 2:34:38 PM > >> Subject: Re: [Mpi-forum] Reserved MPI_ prefix & namespace in C and > >> Fortran > >> So, while we are debating whether the wording is sufficient, > >> we are overlooking a far more important error in the restriction. > >> It is simply wrong. The standard is not consistent. > >> > >> Specifically, when one uses the MPI profiling interface, the > >> mechanism is precisely to declare functions that begin with > >> MPI_. So the intent of the standard is that we are supposed > >> to violate that restriction. This issue has nagged at me in > >> the past but I have simply ignored it. However, I would oppose > >> increasing the scope of the restriction without fixing the > >> real inconsistency. > >> _______________________________________________ > >> mpi-forum mailing list > >> mpi-forum(a)lists.mpi-forum.org > >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > > > > -- > > 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) > > -- 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-forum] Reserved MPI_ prefix & namespace in C and Fortran
by Bronis R. de Supinski 25 Aug '12

25 Aug '12

I agree with Bill that the right solution is a forward reference at the point the restriction is defined. It will be lost if we bury it in the tools chapter. On Sat, 25 Aug 2012, Rolf Rabenseifner wrote: > Bronis, Martin, Dave, Kathryn, and all tools people, > > Yes, we should also solve this 2nd inconsistency about > defining MPI_Xxxx with real MPI-names when writing a tools layer, > which is inconsistent with the prefix reservation in Sect. 2.6.2-2.6.4 > with the original wording and also with the new wording below. > > Here, I would propose to relax the prefix reservation defined in > Sections 2.6.2 - 2.6.4 by a sentence in the tools chapter > that refers to Sect. 2.6.2-2.6.4. > > Proposed solution (please take it a s a first draft): > > Add a new sentence after MPI-2.2, Chapter 14 "Profiling", > Sect. 14.2 "Discussion", page 454, line 17, > respectively, after MPI-3.0 Draft 2, Section 14.2 "Profiling", > Sect. 14.2.2 "Discussion", page 558, line 34/35: > > Typically, the profiling interface is used by implementing > a new application or profiling function that has the same > name as an MPI routine and internally calls the corresponding > PMPI routine; this is an exception to the name prefix > reservation rules in Sections 2.6.2 and 2.6.3 on pages 18 and 19. > > Because this is specific to the profiling layer, I would not > stress the wording in the Terms chapter. The right position > is really the tools chapter. > > You, as the tools group may find a better wording and fine grained > position of this sentence. Important is, that this sentence > only solves the existing inconsistency, because this is the scope > of this erratum. > > Okay? Better proposals? Comments? > > ----------------------------------- > Here again the latest version of the text in Sections 2.6.2 - 2.6.4: > > C: >> "Programs must not declare > names (identifiers), e.g., for variables, functions, > constants, types, or macros, >> beginning with the prefix MPI_." > > Fortran: >> "Programs must not declare > names, e.g., for variables, subroutines, functions, > parameters, derived types, abstract interfaces, or modules, >> beginning with the prefix MPI_. > > and for Fortran also "subroutines and functions" instead of > only "functions" in the sentence about PMPI_. > > C++ >> "Programs must not declare > names (identifiers), e.g., for variables, functions, > constants, types, or macros, >> in the namespace MPI." > ----------------------------------- > > Best regards > Rolf > > ----- Original Message ----- >> From: "Bronis R. de Supinski" <bronis(a)llnl.gov> >> To: "Main MPI Forum mailing list" <mpi-forum(a)lists.mpi-forum.org> >> Sent: Saturday, August 25, 2012 2:34:38 PM >> Subject: Re: [Mpi-forum] Reserved MPI_ prefix & namespace in C and Fortran >> So, while we are debating whether the wording is sufficient, >> we are overlooking a far more important error in the restriction. >> It is simply wrong. The standard is not consistent. >> >> Specifically, when one uses the MPI profiling interface, the >> mechanism is precisely to declare functions that begin with >> MPI_. So the intent of the standard is that we are supposed >> to violate that restriction. This issue has nagged at me in >> the past but I have simply ignored it. However, I would oppose >> increasing the scope of the restriction without fixing the >> real inconsistency. >> _______________________________________________ >> mpi-forum mailing list >> mpi-forum(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > > -- > 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