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

Sept Meeting
by Richard Graham 29 Aug '12

29 Aug '12

As usual, registration at this stage is lagging, but our hosts are asking for a head count, so that they can plan for the required logistics. If you plan to attend, please register ASAP, or let me know that you plan to attend, so that appropriate plans can be made. Thanks, Rich

1 0

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

27 Aug '12

> So the current wording is fine. Okay, I do not change the erratum. ----- Original Message ----- > From: "N.M. Maclaren" <nmm1(a)cam.ac.uk> > To: "Main MPI Forum mailing list" <mpi-forum(a)lists.mpi-forum.org> > Sent: Monday, August 27, 2012 9:29:18 AM > Subject: Re: [Mpi-forum] Reserved MPI_ prefix & namespace in C and Fortran > On Aug 26 2012, Jeremiah Willcock wrote: > > > >Does "linker names" come under any of the categories so far? I know that > >some of the C compiler extensions to set linker names explicitly do not > >treat them as identifiers in the source code. Are those worth adding > >explicitly (to all languages, probably)? > > The technical term in both C and Fortran is "external names", and > Fortran 2003 BIND(C,NAME=...) sets ones that are not identifiers. > So the current wording is fine. > > Just to be really nasty, many systems did/do have the concept of "linker > names" that are beyond any name concept in any of the languages they > support and, despite that, they can clash. But there is no reasonable > way to say "An MPI implementation must avoid provoking its linker into > creating artificial names beginning MPI_". This has arisen in various > language standards, and the universal decision was to keep the > standard's wording simple - even C never got into this one, though it > was raised! > > Regards, > Nick Maclaren. -- 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 27 Aug '12

27 Aug '12

On Aug 26 2012, Jeremiah Willcock wrote: > >Does "linker names" come under any of the categories so far? I know that >some of the C compiler extensions to set linker names explicitly do not >treat them as identifiers in the source code. Are those worth adding >explicitly (to all languages, probably)? The technical term in both C and Fortran is "external names", and Fortran 2003 BIND(C,NAME=...) sets ones that are not identifiers. So the current wording is fine. Just to be really nasty, many systems did/do have the concept of "linker names" that are beyond any name concept in any of the languages they support and, despite that, they can clash. But there is no reasonable way to say "An MPI implementation must avoid provoking its linker into creating artificial names beginning MPI_". This has arisen in various language standards, and the universal decision was to keep the standard's wording simple - even C never got into this one, though it was raised! Regards, Nick Maclaren.

1 0

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

26 Aug '12

On Sun, 26 Aug 2012, Rolf Rabenseifner wrote: > I updated the ticket 343 with the now hopefully final text > for the terms chapter (after Bronis', Bill's and Martin's comments) > see > https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/343 > and the files attached to the ticket. > > I hope that now all can agree with this correction of the > existing inconsistency as detected in the public review > and discussed in the previous emails. > Fortran: >> "Programs must not declare > names, e.g., for variables, subroutines, functions, > parameters, derived types, abstract interfaces, or modules, >> beginning with the prefix MPI_. >> To avoid conflicting with the profiling interface, programs > must >> also avoid > subroutines and >> functions with the prefix PMPI_." Does "linker names" come under any of the categories so far? I know that some of the C compiler extensions to set linker names explicitly do not treat them as identifiers in the source code. Are those worth adding explicitly (to all languages, probably)? -- Jeremiah Willcock

1 0

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

26 Aug '12

Thanks - fixing the must -> shall (like the illegal -> invalid) is something for MPI-next. There are currently are large number of "must"s in the document. 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 11:47 AM, N.M. Maclaren wrote: > On Aug 26 2012, Rolf Rabenseifner wrote: >> >> About 1.: Yes, agreed. Always must and should are used as >> synonyms in the scope of standards. To use the same >> words in both sentences is clarifying that there is >> no relevant difference in the meaning. > > Sorry, but definitely not in ISO standards! From ISO > Directives Part 2: > > Table H.1 - Requirement > Verbal form Equivalent expressions > shall is to > is required to > it is required that > has to > only ... is permitted > it is necessary > shall not is not allowed [permitted] [acceptable] [permissible] > is required to be not > is required that ... be not > is not to be > > Do not use "must" as an alternative for "shall". (This will avoid any > confusion between the requirements of a document and external statutory > obligations.) Do not use "may not" instead of "shall not" to express a > prohibition. > > Table H.2 - Recommendation > Verbal form Equivalent expressions > should it is recommended that > ought to > should not it is not recommended that > ought not to > > [End of extract] > > However, in non-ISO standards (and fairly often even in them!, "must" > is used as a synonym for "shall". It is definitely never a synonym > for "should". > > Regards, > Nick Maclaren. > > > _______________________________________________ > 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 N.M. Maclaren 26 Aug '12

26 Aug '12

On Aug 26 2012, Rolf Rabenseifner wrote: > >About 1.: Yes, agreed. Always must and should are used as >synonyms in the scope of standards. To use the same >words in both sentences is clarifying that there is >no relevant difference in the meaning. Sorry, but definitely not in ISO standards! From ISO Directives Part 2: Table H.1 - Requirement Verbal form Equivalent expressions shall is to is required to it is required that has to only ... is permitted it is necessary shall not is not allowed [permitted] [acceptable] [permissible] is required to be not is required that ... be not is not to be Do not use "must" as an alternative for "shall". (This will avoid any confusion between the requirements of a document and external statutory obligations.) Do not use "may not" instead of "shall not" to express a prohibition. Table H.2 - Recommendation Verbal form Equivalent expressions should it is recommended that ought to should not it is not recommended that ought not to [End of extract] However, in non-ISO standards (and fairly often even in them!, "must" is used as a synonym for "shall". It is definitely never a synonym for "should". 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

I updated the ticket 343 with the now hopefully final text for the terms chapter (after Bronis', Bill's and Martin's comments) see https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/343 and the files attached to the ticket. I hope that now all can agree with this correction of the existing inconsistency 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 (modifications indented): C: > "Programs must not declare names (identifiers), e.g., for variables, functions, constants, types, or macros, > beginning with the prefix MPI_. > To support the profiling interface, programs must > not declare functions with names beginning with the prefix PMPI_." Fortran: > "Programs must not declare names, e.g., for variables, subroutines, functions, parameters, derived types, abstract interfaces, or modules, > beginning with the prefix MPI_. > To avoid conflicting with the profiling interface, programs must > also avoid subroutines and > functions with the prefix 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 -- 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 William Gropp 26 Aug '12

26 Aug '12

On 2, I'm ok but I do want to emphasize that the original *intent* of the MPI Forum was to reserve the MPI and PMPI prefix for future versions of the standard - thus *any* limitation on what sort of entity that applies to violates the original *intent*. Yes, the text failed to make that clear, but there is no change or extension intended here. This should also be a cautionary tale about attempting to enumerate everything, particularly in a way that will apply in the future. 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 10:19 AM, Rolf Rabenseifner wrote: > Bill, you ask for two things (here the Fortran text, but C is the same): > >> Programs must not declare >> variables, parameters, or functions with names >> beginning with the prefix MPI_. >> To avoid conflicting with the profiling interface, programs >> should also avoid functions with the prefix PMPI_. > > The first sentence, we substituted already by >> Programs must not declare > names, e.g., for variables, subroutines, functions, > parameters, derived types, abstract interfaces, or modules, >> beginning with the prefix MPI_. > > You ask in the second sentence for > 1. Substitute "should" by "must" in the last line > 2. Substitute "functions" by "name". > > About 1.: Yes, agreed. Always must and should are used as > synonyms in the scope of standards. To use the same > words in both sentences is clarifying that there is > no relevant difference in the meaning. > > About 2.: I do not see that it is needed, > i.e., that there is an inconsistency, > and the MPI-1 Forum decided to make a clear difference > between MPI > - where all names must be restricted, > - as we now do, > and PMPI > - where conflicts are only for routines because we > do not have any PMPI name for other areas. > > Therefore for me, the 2. topic would be out of the scope > of this erratum. > And I want to keep it as an erratum, because it should > be done before we vote on MPI-3.0 and therefore automatically > included in MPI-3.0. > > Okay? > > Rolf > > > ----- Original Message ----- >> From: "William Gropp" <wgropp(a)illinois.edu> >> To: "Main MPI Forum mailing list" <mpi-forum(a)lists.mpi-forum.org> >> Sent: Sunday, August 26, 2012 4:28:22 PM >> Subject: Re: [Mpi-forum] Reserved MPI_ prefix & namespace in C and Fortran >> 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 >> >> >> _______________________________________________ >> 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) > _______________________________________________ > 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 Schulz, Martin 26 Aug '12

26 Aug '12

Sure, that makes sense and is fine with me. Martin On Aug 26, 2012, at 4:47 AM, 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? >> >> 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) >> ________________________________________________________________________ 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 Rolf Rabenseifner 26 Aug '12

26 Aug '12

Bill, you ask for two things (here the Fortran text, but C is the same): > Programs must not declare > variables, parameters, or functions with names > beginning with the prefix MPI_. > To avoid conflicting with the profiling interface, programs > should also avoid functions with the prefix PMPI_. The first sentence, we substituted already by > Programs must not declare names, e.g., for variables, subroutines, functions, parameters, derived types, abstract interfaces, or modules, > beginning with the prefix MPI_. You ask in the second sentence for 1. Substitute "should" by "must" in the last line 2. Substitute "functions" by "name". About 1.: Yes, agreed. Always must and should are used as synonyms in the scope of standards. To use the same words in both sentences is clarifying that there is no relevant difference in the meaning. About 2.: I do not see that it is needed, i.e., that there is an inconsistency, and the MPI-1 Forum decided to make a clear difference between MPI - where all names must be restricted, - as we now do, and PMPI - where conflicts are only for routines because we do not have any PMPI name for other areas. Therefore for me, the 2. topic would be out of the scope of this erratum. And I want to keep it as an erratum, because it should be done before we vote on MPI-3.0 and therefore automatically included in MPI-3.0. Okay? Rolf ----- Original Message ----- > From: "William Gropp" <wgropp(a)illinois.edu> > To: "Main MPI Forum mailing list" <mpi-forum(a)lists.mpi-forum.org> > Sent: Sunday, August 26, 2012 4:28:22 PM > Subject: Re: [Mpi-forum] Reserved MPI_ prefix & namespace in C and Fortran > 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 > > > _______________________________________________ > 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