[Mpi-forum] Reserved MPI_ prefix & namespace in C and Fortran
Schulz, Martin
schulzm at llnl.gov
Sun Aug 26 00:48:07 CDT 2012
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
More information about the mpi-forum
mailing list