[mpiwg-tools] Ticket 358

Wed Feb 4 10:19:12 CST 2015

Just to beat this dead horse some more, I agree with Kathryn.
Marc-Andre's suggestion might be a great guideline for a measurement tool,
but the interface has uses beyond tools.  The ULFM example is a good
example of using it for prototyping new functionality.  There's no reason
to prohibit this.

On 2/4/15, 9:11 AM, "Kathryn Mohror" <kathryn at llnl.gov> wrote:

>I agree with Bronis that the language is unnecessary and think attempting
>to define correct usage may actually prohibit useful libraries from doing
>their jobs. As an example from the notes from our discussion on 1/8:
>
>* ULFM proposal: library may do various activities behind the scenes,
>e.g., repair communicators, restore lost messages, so that eventually all
>processes will be in a recovered state. However, there could be some
>amount of time where the original MPI usage semantics were not strictly
>followed
>
>I argue for leaving it alone. Attempting to define it could prove to be
>complicated enough that we end up accidentally prohibiting functionality.
>It has not been a problem to date, and interesting uses of the interface
>have come about that don't strictly follow the original MPI semantics.
>
>
>Kathryn
>_________________________________________________________________
>Kathryn Mohror, kathryn at llnl.gov, http://scalability.llnl.gov/
>Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA,
>USA
>
>
>
>
>
>
>On 2/4/15, 6:15 AM, "Bronis R. de Supinski" <bronis at llnl.gov> wrote:
>
>>
>>Yes, my answer is no. The only statement that would be
>>appropriate for the standard is "Redefining any MPI
>>function to provide semantics inconsistent with the
>>standard can result in a non-conformant execution."
>>However, the statement is a tautology so it is unnecessary.
>>
>>On Wed, 4 Feb 2015, Marc-Andre Hermanns wrote:
>>
>>> Bronis,
>>>
>>> I don't claim that the use of the profiling interface has any influence
>>> on the conformance of the MPI implementation, and you are right that it
>>> doesn't, as the re-defined code is not part of the implementation but
>>> some third-party software.
>>>
>>> Yet, the standard could very well state what falls under "standard
>>> conformant use" (not implementation!) of the interface. Something like
>>> "whatever you do, don't make correct MPI applications fail." The
>>> question is only: Should it? (And I take your answer to be no.)
>>>
>>> Cheers,
>>> Marc-Andre
>>>
>>> On 04.02.15 12:48, Bronis R. de Supinski wrote:
>>>>
>>>> I do not see why your proposal is necessary or apprpriate.
>>>> If I want to redefine MPI_Send to be MPI_Recv (or more
>>>> likely to send to /dev/null) I can do it. THe MPI standard
>>>> cannot prohibit it and it has no impact on the conformance
>>>> of the implementation that I am using.
>>>>
>>>>
>>>>
>>>> On Tue, 3 Feb 2015, Marc-Andre Hermanns wrote:
>>>>
>>>>> Hi Martin,
>>>>>
>>>>> I see Rolf's point, although I am am unsure whether the initial
>>>>>wording
>>>>> of the change in 453 is correct.
>>>>>
>>>>> If you see it from the C perspective, declaration and definition are
>>>>>two
>>>>> separate things. However, the standard only talks about declaration
>>>>>of
>>>>> functions in the MPI_ namespace. That, IMHO, should never be allowed.
>>>>> What should be allowed is to "define already declared functions in
>>>>>the
>>>>> MPI_ namespace."
>>>>>
>>>>> I am unsure whether Fortran also has this distinction. C/C++
>>>>>certainly
>>>>> has. If we now allow the _declaration_ of calls in the MPI_
>>>>>namespace,
>>>>> then it would allow me to define MPI_Whatever(), which I think should
>>>>> still not be allowed.
>>>>>
>>>>> Off the cuff, I would try to find a wording that goes along the lines
>>>>>of:
>>>>>
>>>>> "... any redefined function in the MPI_ namespace must guarantee the
>>>>> semantics defined in the standard, but is allowed to have additional
>>>>> side effects".
>>>>>
>>>>> This is too rough cut, still. Yet, what I want to express is that any
>>>>> re-definition should not change the expected behavior of the call.
>>>>>
>>>>> Examples:
>>>>> - A non-blocking call should not suddenly block.
>>>>> - A blocking call must still ensure that the user buffer can safely
>>>>>be
>>>>> re-used after the call returns.
>>>>> - A broadcast should still be a call where the source of the data is
>>>>>the
>>>>> root and after completion all other processes have a copy of the
>>>>>root's
>>>>> buffer. (and not suddenly implement a reduce).
>>>>>
>>>>> This would still cover MPIEcho, because the additional MPI_Sends on
>>>>>the
>>>>> slave processes can be regarded as side effects, right?. The
>>>>>application
>>>>> still just sees the expected behavior of one message being sent from
>>>>> process to process.
>>>>>
>>>>> Cheers,
>>>>> Marc-Andre
>>>>>
>>>>> On 04.02.15 06:17, Schulz Martin wrote:
>>>>>> I am still not convinced we need this, but if we find the right
>>>>>> language I
>>>>>> am not opposed to it. Not sure, how we can write this the right way.
>>>>>> This
>>>>>> gets fuzzy very easily. Do you have a suggestion?
>>>>>>
>>>>>> Martin
>>>>>>
>>>>>> 
>>>>>>_____________________________________________________________________
>>>>>>_
>>>>>>__
>>>>>> Martin Schulz, schulzm at llnl.gov, http://scalability.llnl.gov/
>>>>>> CASC @ Lawrence Livermore National Laboratory, Livermore, USA
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 2/3/15, 8:37 AM, "Marc-Andre Hermanns" <m.a.hermanns at grs-sim.de>
>>>>>> wrote:
>>>>>>
>>>>>>> Dear all,
>>>>>>>
>>>>>>> I just got a chance to talk to Rolf on this ticket:
>>>>>>> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/358
>>>>>>>
>>>>>>> The reason for this ticket was that in ticket 453
>>>>>>> (https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/453), which
>>>>>>>passed
>>>>>>> as 3.0 errata, it is now explicitly allowed to declare functions in
>>>>>>>the
>>>>>>> MPI_ namespace, as long as the user wants to make use of the
>>>>>>>profiling
>>>>>>> interface.
>>>>>>>
>>>>>>> The question now is, whether we should have a clarifying sentence
>>>>>>>in
>>>>>>> the
>>>>>>> profiling chapter to tell users of the interface not to tamper with
>>>>>>>the
>>>>>>> existing semantics of specific calls.
>>>>>>>
>>>>>>> Rolf understood that the current wording in the ticket may be too
>>>>>>> ristrictive, as it remains unclear what 'fully conforms' still
>>>>>>>allows.
>>>>>>> His suggestion was maybe a less restrictive wording, where tools
>>>>>>>like
>>>>>>> MPIEcho are still allowed.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Marc-Andre
>>>>>>> --
>>>>>>> Marc-Andre Hermanns
>>>>>>> Jülich Aachen Research Alliance,
>>>>>>> High Performance Computing (JARA-HPC)
>>>>>>> German Research School for Simulation Sciences GmbH
>>>>>>>
>>>>>>> Schinkelstrasse 2
>>>>>>> 52062 Aachen
>>>>>>> Germany
>>>>>>>
>>>>>>> Phone: +49 241 80 99753
>>>>>>> Fax: +49 241 80 6 99753
>>>>>>> www.grs-sim.de/parallel
>>>>>>> email: m.a.hermanns at grs-sim.de
>>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> mpiwg-tools mailing list
>>>>>> mpiwg-tools at lists.mpi-forum.org
>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools
>>>>>>
>>>>>
>>>>> --
>>>>> Marc-Andre Hermanns
>>>>> Jülich Aachen Research Alliance,
>>>>> High Performance Computing (JARA-HPC)
>>>>> German Research School for Simulation Sciences GmbH
>>>>>
>>>>> Schinkelstrasse 2
>>>>> 52062 Aachen
>>>>> Germany
>>>>>
>>>>> Phone: +49 241 80 99753
>>>>> Fax: +49 241 80 6 99753
>>>>> www.grs-sim.de/parallel
>>>>> email: m.a.hermanns at grs-sim.de
>>>>>
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> mpiwg-tools mailing list
>>>> mpiwg-tools at lists.mpi-forum.org
>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools
>>>>
>>>
>>> -- 
>>> Marc-Andre Hermanns
>>> Jülich Aachen Research Alliance,
>>> High Performance Computing (JARA-HPC)
>>> German Research School for Simulation Sciences GmbH
>>>
>>> Schinkelstrasse 2
>>> 52062 Aachen
>>> Germany
>>>
>>> Phone: +49 241 80 99753
>>> Fax: +49 241 80 6 99753
>>> www.grs-sim.de/parallel
>>> email: m.a.hermanns at grs-sim.de
>>>
>
>
>_______________________________________________
>mpiwg-tools mailing list
>mpiwg-tools at lists.mpi-forum.org
>http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools