- mpiwg-p2p - mailman3.cels.anl.gov

Next meeting: 2nd February 2015 11am Central US
by Daniel Holmes 29 Jan '15

29 Jan '15

Hi All, The next point-to-point teleconference /could be/ on Monday 2nd February 2015 at 11am Central US via webex. Connection details are on the point-to-point wiki page: https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/PtpWikiPage ** I will not be able to attend. If the meeting goes ahead, please nominate one attendee to take notes and post them to the wiki page ** There isn't much to discuss, I think. Agenda: 1) Do we want WG time at the March face-to-face meeting? I am assuming "yes" but I don't have a good estimate of how much time is desired. 2) "Can INFO keys change the semantic behaviour of MPI?" issue - Jim is working on a possible solution but this is not yet ready for WG discussion. 3) Progress on Arecv and Fsend 4) Other stuff? Updates/comments by email to this list (rather than a teleconference) are probably sufficient this time. Cheers, Dan. -- Dan Holmes Applications Consultant in HPC Research EPCC, The University of Edinburgh James Clerk Maxwell Building The Kings Buildings Peter Guthrie Tait Road Edinburgh EH9 3FD T: +44(0)131 651 3465 E: dholmes(a)epcc.ed.ac.uk *Please consider the environment before printing this email.* The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

1 0

Re: [mpiwg-p2p] how to classify ticket 471 ("MPI_START(ALL) restrictions")?
by Jeff Hammond 19 Jan '15

19 Jan '15

I missed "The associated request should be inactive." in the MPI_START semantics, which resolves a lot of my issues in favor of what Dan said on the telecon today. Jeff On Fri, Jan 16, 2015 at 10:54 AM, Jeff Hammond <jeff.science(a)gmail.com> wrote: > Thanks for your comments, Dan. > >> MPI 3.0 p78 lines 18-25 (section 3.9) forces the correct sequence and >> explicitly calls out the case of multiple concurrent threads. > > My reading of the text of lines 14-18 is to constrain the use of > MPI_REQUEST_FREE and nothing else. It so happens that line 21 > _implies_ additional restrictions, but these are not stated. And > given that line 21 is preceded by "If this rule [pertaining to > MPI_REQUEST_FREE] is followed..." it is not unreasonable to interpret > line 21 as a non-normative illustration of the rule described in > 14-18. > > Only if one reads line 21 as both normative and itself a constraint on > its own (i.e. ignoring its relationship to lines 14-18), does one > conclude that starting a request twice without completing it first is > prohibited. > >> Also, a MPI_STARTALL call "has the same effect as" lots of MPI_START calls >> "in some arbitrary order" p78 lines 5-7 plus "the request should be >> inactive... becomes active once the call is made" p77 lines 28-29 so >> specifying a request more than once in the vector to MPI_STARTALL is pretty >> much guaranteed to break the correct sequence and the chronologically second >> implied MPI_START will be supplied with an active request, which is defined >> to be bad. > > I agree that the constraint on STARTALL follows immediately once it is > established for START. > >> I think that section 3.9 is fine and deals with all your points of possible >> ambiguity. Section 12 then incorrectly tries to un-write some of those rules >> by absent-mindedly neglecting the existence of persistent requests. Changing >> the text you quote (section 12.4.3), in particular "In MPI, a request can >> only be completed once" - *buzzz*, fail - is, IMHO, errata because the >> Standard is semantically (rather than just syntactically) wrong and needs to >> be corrected. Determining ticket-0 on this is a matter for the External >> Interfaces chapter committee. An errata could be brought by this WG because >> it is point-to-point functionality that is causing the conflict or by the >> Hybrid WG because it is all the fault of those pesky threads again. > > I recall that am one of the very few members of that chapter > committee. I will propose changes for the external interfaces chapter > that I will then argue in the corresponding chapter committee context > are ticket-0 :-) > > Best, > > Jeff > >> On 16/01/2015 17:00, Jeff Hammond wrote: >>> >>> I created https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/471 last >>> night. Jim and Sayantan the overall concept is noncontroversial. >>> >>> Is this ticket-0, an errata, or something that has to be read for MPI-4? >>> >>> Thanks, >>> >>> Jeff >>> >> >> >> -- >> The University of Edinburgh is a charitable body, registered in >> Scotland, with registration number SC005336. >> >> _______________________________________________ >> mpiwg-p2p mailing list >> mpiwg-p2p(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-p2p > > > > -- > Jeff Hammond > jeff.science(a)gmail.com > http://jeffhammond.github.io/ -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0

Re: [mpiwg-p2p] how to classify ticket 471 ("MPI_START(ALL) restrictions")?
by Jeff Hammond 16 Jan '15

16 Jan '15

Thanks for your comments, Dan. > MPI 3.0 p78 lines 18-25 (section 3.9) forces the correct sequence and > explicitly calls out the case of multiple concurrent threads. My reading of the text of lines 14-18 is to constrain the use of MPI_REQUEST_FREE and nothing else. It so happens that line 21 _implies_ additional restrictions, but these are not stated. And given that line 21 is preceded by "If this rule [pertaining to MPI_REQUEST_FREE] is followed..." it is not unreasonable to interpret line 21 as a non-normative illustration of the rule described in 14-18. Only if one reads line 21 as both normative and itself a constraint on its own (i.e. ignoring its relationship to lines 14-18), does one conclude that starting a request twice without completing it first is prohibited. > Also, a MPI_STARTALL call "has the same effect as" lots of MPI_START calls > "in some arbitrary order" p78 lines 5-7 plus "the request should be > inactive... becomes active once the call is made" p77 lines 28-29 so > specifying a request more than once in the vector to MPI_STARTALL is pretty > much guaranteed to break the correct sequence and the chronologically second > implied MPI_START will be supplied with an active request, which is defined > to be bad. I agree that the constraint on STARTALL follows immediately once it is established for START. > I think that section 3.9 is fine and deals with all your points of possible > ambiguity. Section 12 then incorrectly tries to un-write some of those rules > by absent-mindedly neglecting the existence of persistent requests. Changing > the text you quote (section 12.4.3), in particular "In MPI, a request can > only be completed once" - *buzzz*, fail - is, IMHO, errata because the > Standard is semantically (rather than just syntactically) wrong and needs to > be corrected. Determining ticket-0 on this is a matter for the External > Interfaces chapter committee. An errata could be brought by this WG because > it is point-to-point functionality that is causing the conflict or by the > Hybrid WG because it is all the fault of those pesky threads again. I recall that am one of the very few members of that chapter committee. I will propose changes for the external interfaces chapter that I will then argue in the corresponding chapter committee context are ticket-0 :-) Best, Jeff > On 16/01/2015 17:00, Jeff Hammond wrote: >> >> I created https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/471 last >> night. Jim and Sayantan the overall concept is noncontroversial. >> >> Is this ticket-0, an errata, or something that has to be read for MPI-4? >> >> Thanks, >> >> Jeff >> > > > -- > The University of Edinburgh is a charitable body, registered in > Scotland, with registration number SC005336. > > _______________________________________________ > mpiwg-p2p mailing list > mpiwg-p2p(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-p2p -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0

Re: [mpiwg-p2p] how to classify ticket 471 ("MPI_START(ALL) restrictions")?
by Dan Holmes 16 Jan '15

16 Jan '15

Hi Jeff, MPI 3.0 p78 lines 18-25 (section 3.9) forces the correct sequence and explicitly calls out the case of multiple concurrent threads. Also, a MPI_STARTALL call "has the same effect as" lots of MPI_START calls "in some arbitrary order" p78 lines 5-7 plus "the request should be inactive... becomes active once the call is made" p77 lines 28-29 so specifying a request more than once in the vector to MPI_STARTALL is pretty much guaranteed to break the correct sequence and the chronologically second implied MPI_START will be supplied with an active request, which is defined to be bad. I think that section 3.9 is fine and deals with all your points of possible ambiguity. Section 12 then incorrectly tries to un-write some of those rules by absent-mindedly neglecting the existence of persistent requests. Changing the text you quote (section 12.4.3), in particular "In MPI, a request can only be completed once" - *buzzz*, fail - is, IMHO, errata because the Standard is semantically (rather than just syntactically) wrong and needs to be corrected. Determining ticket-0 on this is a matter for the External Interfaces chapter committee. An errata could be brought by this WG because it is point-to-point functionality that is causing the conflict or by the Hybrid WG because it is all the fault of those pesky threads again. Cheers, Dan. On 16/01/2015 17:00, Jeff Hammond wrote: > I created https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/471 last > night. Jim and Sayantan the overall concept is noncontroversial. > > Is this ticket-0, an errata, or something that has to be read for MPI-4? > > Thanks, > > Jeff > -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

1 0

Re: [mpiwg-p2p] Next meeting: 19th January 2015 11am Central US
by Jeff Hammond 16 Jan '15

16 Jan '15

I'd like to discuss https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/471. Jeff On Fri, Jan 16, 2015 at 4:34 AM, Daniel Holmes <dholmes(a)epcc.ed.ac.uk> wrote: > Hi All, > > The next point-to-point teleconference will be on Monday 19th January 2015 > at 11am Central US via webex. > > Connection details are on the point-to-point wiki page: > https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/PtpWikiPage > > Agenda: > 1) New INFO keys - specifically the "can INFO keys change the semantic > behaviour of MPI?" issue (see summary from Jim below) > 2) Progress on Arecv and Fsend > 3) Other stuff? > > Cheers, > Dan. > > On 12/01/2015 15:39, Jim Dinan wrote: >> >> Hi All, >> >> Apologies for missing the meeting. There was a lot of discussion at the >> Forum about the validity of restricting the application's behavior using >> info keys (or, if you prefer, the application asserting its behavior through >> info keys). Folks indicated that this qualifies as a semantic change for >> the given communicator, which is forbidden by Section 6.4.4 and made more >> complicated because MPI_Comm_dup propagates info keys. >> >> In response to this feedback, I started working on a straw man >> communicator assertions interface that would allow the application to assert >> what its behavior will be. I will prepare this for discussion at a future >> WG meeting. >> >> In parallel, I have had discussions with others who feel that the opinion >> expressed at the Forum meeting is incorrect; that it should be valid to >> provide hints on application behavior through info keys. >> >> At the same time, the straw vote at the December meeting indicated that >> the Forum as a whole would like to pursue this capability for the MPI >> standard. So, much more discussion and debate is needed. Looking forward >> to it, >> >> ~Jim. > > > -- > Dan Holmes > Applications Consultant in HPC Research > EPCC, The University of Edinburgh > James Clerk Maxwell Building > The Kings Buildings > Peter Guthrie Tait Road > Edinburgh > EH9 3FD > T: +44(0)131 651 3465 > E: dholmes(a)epcc.ed.ac.uk > > *Please consider the environment before printing this email.* > > > The University of Edinburgh is a charitable body, registered in > Scotland, with registration number SC005336. > > _______________________________________________ > mpiwg-p2p mailing list > mpiwg-p2p(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-p2p -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0

how to classify ticket 471 ("MPI_START(ALL) restrictions")?
by Jeff Hammond 16 Jan '15

16 Jan '15

I created https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/471 last night. Jim and Sayantan the overall concept is noncontroversial. Is this ticket-0, an errata, or something that has to be read for MPI-4? Thanks, Jeff -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0

Next meeting: 19th January 2015 11am Central US
by Daniel Holmes 16 Jan '15

16 Jan '15

Hi All, The next point-to-point teleconference will be on Monday 19th January 2015 at 11am Central US via webex. Connection details are on the point-to-point wiki page: https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/PtpWikiPage Agenda: 1) New INFO keys - specifically the "can INFO keys change the semantic behaviour of MPI?" issue (see summary from Jim below) 2) Progress on Arecv and Fsend 3) Other stuff? Cheers, Dan. On 12/01/2015 15:39, Jim Dinan wrote: > Hi All, > > Apologies for missing the meeting. There was a lot of discussion at > the Forum about the validity of restricting the application's behavior > using info keys (or, if you prefer, the application asserting its > behavior through info keys). Folks indicated that this qualifies as a > semantic change for the given communicator, which is forbidden by > Section 6.4.4 and made more complicated because MPI_Comm_dup > propagates info keys. > > In response to this feedback, I started working on a straw man > communicator assertions interface that would allow the application to > assert what its behavior will be. I will prepare this for discussion > at a future WG meeting. > > In parallel, I have had discussions with others who feel that the > opinion expressed at the Forum meeting is incorrect; that it should be > valid to provide hints on application behavior through info keys. > > At the same time, the straw vote at the December meeting indicated > that the Forum as a whole would like to pursue this capability for the > MPI standard. So, much more discussion and debate is needed. Looking > forward to it, > > ~Jim. -- Dan Holmes Applications Consultant in HPC Research EPCC, The University of Edinburgh James Clerk Maxwell Building The Kings Buildings Peter Guthrie Tait Road Edinburgh EH9 3FD T: +44(0)131 651 3465 E: dholmes(a)epcc.ed.ac.uk *Please consider the environment before printing this email.* The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

1 0

Re: [mpiwg-p2p] Next meeting: 5th January 2015 11am Central US
by Jim Dinan 12 Jan '15

12 Jan '15

Hi All, Apologies for missing the meeting. There was a lot of discussion at the Forum about the validity of restricting the application's behavior using info keys (or, if you prefer, the application asserting its behavior through info keys). Folks indicated that this qualifies as a semantic change for the given communicator, which is forbidden by Section 6.4.4 and made more complicated because MPI_Comm_dup propagates info keys. In response to this feedback, I started working on a straw man communicator assertions interface that would allow the application to assert what its behavior will be. I will prepare this for discussion at a future WG meeting. In parallel, I have had discussions with others who feel that the opinion expressed at the Forum meeting is incorrect; that it should be valid to provide hints on application behavior through info keys. At the same time, the straw vote at the December meeting indicated that the Forum as a whole would like to pursue this capability for the MPI standard. So, much more discussion and debate is needed. Looking forward to it, ~Jim. On Mon, Jan 5, 2015 at 6:43 AM, Daniel Holmes <dholmes(a)epcc.ed.ac.uk> wrote: > Hi All, > > The next point-to-point teleconference will be - today, in about 5 hours - > on Monday 5th January 2015 at 11am Central US via webex. > > Connection details are on the point-to-point wiki page: > https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/PtpWikiPage > > Agenda: > 1) Review of December Forum meeting > 2) Changes to the Point to Point chapter for MPI 3.1 > 3) Streams - possible overlap with newly re-formed Persistence WG > 4) New INFO keys - specifically the one to enable adaptive routing > 5) Arecv and Fsend > 6) Other stuff? > > Cheers, > Dan. > > -- > Dan Holmes > Applications Consultant in HPC Research > EPCC, The University of Edinburgh > James Clerk Maxwell Building > The Kings Buildings > Peter Guthrie Tait Road > Edinburgh > EH9 3FD > T: +44(0)131 651 3465 > E: dholmes(a)epcc.ed.ac.uk > > *Please consider the environment before printing this email.* > > The University of Edinburgh is a charitable body, registered in > Scotland, with registration number SC005336. > > _______________________________________________ > mpiwg-p2p mailing list > mpiwg-p2p(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-p2p >

1 0

Next meeting: 5th January 2015 11am Central US
by Daniel Holmes 05 Jan '15

05 Jan '15

Hi All, The next point-to-point teleconference will be - today, in about 5 hours - on Monday 5th January 2015 at 11am Central US via webex. Connection details are on the point-to-point wiki page: https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/PtpWikiPage Agenda: 1) Review of December Forum meeting 2) Changes to the Point to Point chapter for MPI 3.1 3) Streams - possible overlap with newly re-formed Persistence WG 4) New INFO keys - specifically the one to enable adaptive routing 5) Arecv and Fsend 6) Other stuff? Cheers, Dan. -- Dan Holmes Applications Consultant in HPC Research EPCC, The University of Edinburgh James Clerk Maxwell Building The Kings Buildings Peter Guthrie Tait Road Edinburgh EH9 3FD T: +44(0)131 651 3465 E: dholmes(a)epcc.ed.ac.uk *Please consider the environment before printing this email.* The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

1 0

Slide of the Channel
by Takeshi Nanri 09 Dec '14

09 Dec '14

Hi all, Please find attached the slide of my talk about Channel, today. As far as I remember, the comments on the talk can be summarized as the following two topics: - Feasibility of the idea is not shown. There should be technical details about how the low memory consumption can be achieved. First, the method for minimizing the memory consumption by MPI_COMM_WORLD need to be shown. (May be by runtime options or MPI_Freeze) Then, with this situation, the mechanisms for establishing connections of channels shoulde be introduced. - Requirement for this is not explicit. At this point, there have been no requirements for dynamic disconnection. (That is why this kind of technique has not been implemented in major MPI libraries.) Adaptive Mesh can be a candidate. But, at this point, there is no complain about the memory consumption of communication library from the programmers in that field. Please notify me if there is anything I'm missing. Regards, Takeshi Nanri Kyushu University

1 0