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(a)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(a)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(a)grs-sim.de
>>>
>>
>>
>> _______________________________________________
>> mpiwg-tools mailing list
>> mpiwg-tools(a)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(a)grs-sim.de
>
>
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(a)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(a)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(a)grs-sim.de
>>
>
>
> _______________________________________________
> mpiwg-tools mailing list
> mpiwg-tools(a)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(a)grs-sim.de
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(a)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(a)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(a)grs-sim.de
>
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(a)grs-sim.de
