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

Schulz, Martin schulzm at llnl.gov
Sun Aug 26 10:29:51 CDT 2012 

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

________________________________________________________________________
Martin Schulz, schulzm at llnl.gov, http://people.llnl.gov/schulzm
CASC @ Lawrence Livermore National Laboratory, Livermore, USA

More information about the mpi-forum mailing list