February 2015 - mpiwg-tools - mailman3.cels.anl.gov

Notes from meetings
by Mohror, Kathryn 26 Feb '15

26 Feb '15

Hi all, There are notes from the last tools WG meeting here: https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/MPI3Tools/notes-2015-02-1 9 There are notes from a separate meeting discussing the MPI Handles Interface work that was done last summer here: https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/MPI3Tools/notes-2015-02-2 5 Kathryn _________________________________________________________________ Kathryn Mohror, kathryn(a)llnl.gov, http://scalability.llnl.gov/ Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, USA

1 0

Reminder: meeting tomorrow Thursday 2/19 11 AM EST, 8 AM PST
by Mohror, Kathryn 18 Feb '15

18 Feb '15

Hi everybody, This is a reminder of our regular meeting tomorrow at 11 AM EST, 8 AM PST. As always, the link to join the webex meeting is on the wiki: https://cisco.webex.com/ciscosales/j.php?ED=217124297&UID=0&PW=NMDEyN2UwZmM 3&RT=MiMxMQ%3D%3D As far as agenda goes, let's go through items for the 3.1 reading in a couple weeks. I have not received any feedback beyond what I got from the chapter committee and Jeff, so that should be short. We have one open issue for ticket #387, which we are waiting on a determination from the steering committee I think. Since that should be short, we could spend the rest of the time on in progress items: - #453 - do we need an advice to users for this? - #387 - not this ticket but spun from it - do we need a new error code? Or is it fine? - 14.3.6 - "group" change to "set", new errata - Plan for discussion at f2f Kathryn _________________________________________________________________ Kathryn Mohror, kathryn(a)llnl.gov, http://scalability.llnl.gov/ Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, USA

1 0

Ticket 453
by Marc-Andre Hermanns 06 Feb '15

06 Feb '15

Dear all, I submitted/added a comment to ticket 453 as discussed in the TelCo yesterday. https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/453#comment:11 I hope I phrased everything correctly. The ticket remains related but independent of ticket 358, where we decided yesterday _not_ to add any normative text. The question to everyone now is, whether Bronis' text may qualify as an advice to users, or whether this would still be too much and we should not do anything about this and close the ticket (#358). 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

1 0

Re: [mpiwg-tools] Reminder of our TelCo tomorrow Feb 5, 2015
by Marc-Andre Hermanns 05 Feb '15

05 Feb '15

Dear all, I updated the notes at: https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/MPI3Tools/notes-2015-02-05 with notes of our meeting today. Cheers, Marc-Andre On 04.02.15 21:26, Marc-Andre Hermanns wrote: > Hi all, > > Tomorrow is our regularly scheduled telecon, 8 AM PST, 11 AM EST. As > always, the webex information is on the wiki or you can just click here: > https://cisco.webex.com/ciscosales/j.php?ED=217124297&UID=0&PW=NMDEyN2UwZmM… > > Kathryn might not make it to the call, but she was kind enough to > distill a list of current discussion points. I uploaded them as a > preliminary agenda for the call at: > > https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/MPI3Tools/notes-2015-02-05 > > 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

1 0

Reminder of our TelCo tomorrow Feb 5, 2015
by Marc-Andre Hermanns 04 Feb '15

04 Feb '15

Hi all, Tomorrow is our regularly scheduled telecon, 8 AM PST, 11 AM EST. As always, the webex information is on the wiki or you can just click here: https://cisco.webex.com/ciscosales/j.php?ED=217124297&UID=0&PW=NMDEyN2UwZmM… Kathryn might not make it to the call, but she was kind enough to distill a list of current discussion points. I uploaded them as a preliminary agenda for the call at: https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/MPI3Tools/notes-2015-02-05 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

1 0

Re: [mpiwg-tools] Ticket 358
by Todd Gamblin 04 Feb '15

04 Feb '15

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(a)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(a)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(a)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(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 >>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >>> > > >_______________________________________________ >mpiwg-tools mailing list >mpiwg-tools(a)lists.mpi-forum.org >http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools

1 0

Re: [mpiwg-tools] Ticket 358
by Kathryn Mohror 04 Feb '15

04 Feb '15

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(a)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(a)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(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 >>>> >>>> >>> >>> >>> _______________________________________________ >>> 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 >>

1 0

Re: [mpiwg-tools] Ticket 358
by Bronis R. de Supinski 04 Feb '15

04 Feb '15

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

1 0

Re: [mpiwg-tools] Ticket 358
by Marc-Andre Hermanns 04 Feb '15

04 Feb '15

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

1 0

Re: [mpiwg-tools] Ticket 358
by Jeff Squyres (jsquyres) 04 Feb '15

04 Feb '15

I think MPI-3.0 14.2.2 and 14.2.3 cover the correctness of the situation (i.e., if you provide MPI_Foo, then it must conform to the defined semantics of MPI_Foo). That being said, you have a point about the declared vs. defined language. > On Feb 4, 2015, at 2:28 AM, Marc-Andre Hermanns <m.a.hermanns(a)grs-sim.de> 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 > > _______________________________________________ > mpiwg-tools mailing list > mpiwg-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0