Re: [Mpi-forum] Reserved MPI_ prefix & namespace in C and Fortran
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" <[email protected]> To: "Bronis R. de Supinski" <[email protected]> Cc: "Rolf Rabenseifner" <[email protected]>, "Dave Goodell" <[email protected]>, "Kathryn Mohror" <[email protected]>, "Main MPI Forum mailing list" <[email protected]> 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" <[email protected]> To: "Rolf Rabenseifner" <[email protected]> Cc: "Martin Schulz" <[email protected]>, "Dave Goodell" <[email protected]>, "Kathryn Mohror" <[email protected]>, "Main MPI Forum mailing list" <[email protected]> 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" <[email protected]> To: "Main MPI Forum mailing list" <[email protected]> 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 [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
-- Dr. Rolf Rabenseifner . . . . . . . . . .. email [email protected] 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 [email protected] 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, [email protected], http://people.llnl.gov/schulzm CASC @ Lawrence Livermore National Laboratory, Livermore, USA
-- Dr. Rolf Rabenseifner . . . . . . . . . .. email [email protected] 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, [email protected], http://people.llnl.gov/schulzm CASC @ Lawrence Livermore National Laboratory, Livermore, USA
participants (1)
-
Schulz, Martin