[Mpi-forum] Reserved MPI_ prefix & namespace in C and Fortran

Bronis R. de Supinski bronis at llnl.gov
Sun Aug 26 06:47:45 CDT 2012 

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 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