[Mpi-forum] Reserved MPI_ prefix & namespace in C and Fortran
Rolf Rabenseifner
rabenseifner at hlrs.de
Sun Aug 26 02:08:01 CDT 2012
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 at llnl.gov>
> To: "Bronis R. de Supinski" <bronis at llnl.gov>
> Cc: "Rolf Rabenseifner" <rabenseifner at hlrs.de>, "Dave Goodell" <goodell at mcs.anl.gov>, "Kathryn Mohror"
> <mohror1 at llnl.gov>, "Main MPI Forum mailing list" <mpi-forum at 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 at llnl.gov>
> >>> To: "Rolf Rabenseifner" <rabenseifner at hlrs.de>
> >>> Cc: "Martin Schulz" <schulzm at llnl.gov>, "Dave Goodell"
> >>> <goodell at mcs.anl.gov>, "Kathryn Mohror" <mohror1 at llnl.gov>,
> >>> "Main MPI Forum mailing list" <mpi-forum at 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 at llnl.gov>
> >>>>> To: "Main MPI Forum mailing list"
> >>>>> <mpi-forum at 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 at lists.mpi-forum.org
> >>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
> >>>>
> >>>> --
> >>>> Dr. Rolf Rabenseifner . . . . . . . . . .. email
> >>>> rabenseifner at 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 at 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 at llnl.gov, http://people.llnl.gov/schulzm
> CASC @ Lawrence Livermore National Laboratory, Livermore, USA
--
Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner at 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)
More information about the mpi-forum
mailing list