April 2019 - mpiwg-sessions - mailman3.cels.anl.gov

Re: [mpiwg-sessions] have to miss today's call
by HOLMES Daniel 29 Apr '19

29 Apr '19

Hi all, In that case, I’m going to cancel the meeting this week. Cheers, Dan. — Dr Daniel Holmes PhD Applications Consultant in HPC Research d.holmes(a)epcc.ed.ac.uk<mailto:[email protected]> Phone: +44 (0) 131 651 3465 Mobile: +44 (0) 7940 524 088 Address: Room 2.09, Bayes Centre, 47 Potterrow, Central Area, Edinburgh, EH8 9BT — The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. — On 29 Apr 2019, at 15:18, Pritchard Jr., Howard via mpiwg-sessions <mpiwg-sessions(a)lists.mpi-forum.org<mailto:[email protected]>> wrote: Hi Folks, I’m at an all-day off-site meeting and cannot call in to today’s Sessions WG call. Howard -- Howard Pritchard HPC-ENV Los Alamos National Laboratory _______________________________________________ mpiwg-sessions mailing list mpiwg-sessions(a)lists.mpi-forum.org<mailto:[email protected]> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-sessions

1 0

have to miss today's call
by Pritchard Jr., Howard 29 Apr '19

29 Apr '19

Hi Folks, I’m at an all-day off-site meeting and cannot call in to today’s Sessions WG call. Howard -- Howard Pritchard HPC-ENV Los Alamos National Laboratory

1 0

Re: [mpiwg-sessions] meet today
by HOLMES Daniel 24 Apr '19

24 Apr '19

Hi Martin, what would the process sets actually be? I don’t understand what you are asking here. They are sets of processes. What is not clear? how would you identify communication partners? I don’t understand what you are asking here. Processes are identified in MPI via {comm,rank} tuple. Which processes to communicate with is a user choice. What is not clear? Also, how would you actually create the communicators in an asynchronous way - that part is still collective in the current proposal, which is a bit of an odd semantics for a “socket like” communication. Adding nonblocking communicator creation functions is a separate proposal, orthogonal to the sessions proposal. Do you really want us to tie these things together? Do you (asking in general, not necessarily only Ralph) have a concrete set of use cases to go for and how to support them? Yes. Cheers, Dan. — Dr Daniel Holmes PhD Applications Consultant in HPC Research d.holmes(a)epcc.ed.ac.uk<mailto:[email protected]> Phone: +44 (0) 131 651 3465 Mobile: +44 (0) 7940 524 088 Address: Room 2.09, Bayes Centre, 47 Potterrow, Central Area, Edinburgh, EH8 9BT — The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. — On 24 Apr 2019, at 09:40, Martin Schulz via mpiwg-sessions <mpiwg-sessions(a)lists.mpi-forum.org<mailto:[email protected]>> wrote: Hi Ralph, all, I agree with the below and that we should support that use case. Sessions could indeed be a step in that direction, but something is missing for me in that: what would the process sets actually be and how would you identify communication partners?Also, how would you actually create the communicators in an asynchronous way - that part is still collective in the current proposal, which is a bit of an odd semantics for a “socket like” communication. Do you (asking in general, not necessarily only Ralph) have a concrete set of use cases to go for and how to support them? Thanks, Martin — Prof. Dr. Martin Schulz, Chair of Computer Architecture and Parallel Systems Department of Informatics, TU-Munich, Boltzmannstraße 3, D-85748 Garching Member of the Board of Directors at the Leibniz Supercomputing Centre (LRZ) Email: schulzm(a)in.tum.de<mailto:[email protected]> On 23. Apr 2019, at 19:49, Ralph H Castain via mpiwg-sessions <mpiwg-sessions(a)lists.mpi-forum.org<mailto:[email protected]>> wrote: I cannot speak to the threading issue, but I can say that MPI Sessions is of greater interest than just that area. Specifically, non-traditional programming models are looking for MPI to adopt methods that support async formation and teardown of communicators so they can augment their models with MPI support. Sessions was of interest from that perspective, but if not embraced by the MPI Forum in the not-too-distant future, people will simply drop MPI and go forward with PMIx Groups combined with direct messaging via libfabric or suitable alternative. I think you all know I’m relatively neutral in the debate over programming models. I do fear, however, that MPI is making itself irrelevant by remaining stuck on static behaviors in an increasingly dynamic world. IMO, Sessions represents an interesting attempt to modernize the MPI programming model - I do hope it moves forward soon. Ralph On Apr 23, 2019, at 12:48 PM, Aurelien Bouteiller via mpiwg-sessions <mpiwg-sessions(a)lists.mpi-forum.org<mailto:[email protected]>> wrote: Guys, unfortunately I couldn’t attend the latest telecon, but I have been following the discussion from a distance. I’ll take the time to review the minutes of latest meetings. Is there one in particular that is summarizing the discussion? Now my reticence is not only about thread levels. I really need to get convinced that sessions, as the interface is proposed, is a first step in achieving new capabilities (beyond fixing the threaded initialization problem). Most of the thread-safety capabilities we are talking about, especially when hidden behind the request, can be achieved with per-communicator with INFO keys, for example. Thus, in this case (and some others) sessions, as a concept, are not really improving on the state of the art, or provide a more elegant interface to achieve the goal. I hope that helps clarify my objections, which are not that sessions 'cannot do it’, but more on the line that often ’communicators can do it equally well’. Best, Aurelien On Apr 22, 2019, at 12:47, HOLMES Daniel via mpiwg-sessions <mpiwg-sessions(a)lists.mpi-forum.org<mailto:[email protected]>> wrote: Hi Howard, I’ll be there today. We need to figure out what our purpose is for the meeting on 24th April - or cancel our involvement. Martin added two for us so they existed but we don’t have to use the 2nd one if we have nothing new to present/ask/etc. Point of information: the "function pointers” group just decided today that explicit function pointers as part of the MPI user-facing interface, are not necessary for any of the use-cases for which they were proposed. Thus, we are likely not going to get function pointers + sessions any time ever. This is not a bad thing because one of those driving use-cases for function pointers was sessions - we convinced ourselves that the function pointers needed for sessions, e.g. to support different thread support levels, can be hidden behind the existing MPI functions and opaque handles. For example, the MPI_Request handle could lead to a function pointer for the actual “wait” function inside the MPI library and another for the actual “test” function. The MPI_WAIT and MPI_TEST functions will then be implemented as straightforward delegation shim functions that call down into the appropriate function pointer from the passed-in MPI_Request parameter. We should socialise that proposed approach with Aurelien (in particular) because he voted against sessions in the Chattanooga straw poll because of the perceived lack of support for multiple thread support levels in use at the same time. Cheers, Dan. — Dr Daniel Holmes PhD Applications Consultant in HPC Research d.holmes(a)epcc.ed.ac.uk<mailto:[email protected]> Phone: +44 (0) 131 651 3465 Mobile: +44 (0) 7940 524 088 Address: Room 2.09, Bayes Centre, 47 Potterrow, Central Area, Edinburgh, EH8 9BT — The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. — On 22 Apr 2019, at 17:16, Pritchard Jr., Howard via mpiwg-sessions <mpiwg-sessions(a)lists.mpi-forum.org<mailto:[email protected]>> wrote: HI Sessions activists, If possible, I’d like to meet today to discuss https://github.com/mpiwg-sessions/mpi-standard/pull/27 and https://github.com/mpiwg-sessions/mpi-standard/pull/26 as well as what to knock off next in https://github.com/mpiwg-sessions/sessions-issues/issues/10 Reminder we have an hour in the upcoming virtual forum on 4/24. Thanks, Howard -- Howard Pritchard HPC-ENV Los Alamos National Laboratory _______________________________________________ mpiwg-sessions mailing list mpiwg-sessions(a)lists.mpi-forum.org<mailto:[email protected]> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-sessions _______________________________________________ mpiwg-sessions mailing list mpiwg-sessions(a)lists.mpi-forum.org<mailto:[email protected]> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-sessions _______________________________________________ mpiwg-sessions mailing list mpiwg-sessions(a)lists.mpi-forum.org<mailto:[email protected]> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-sessions _______________________________________________ mpiwg-sessions mailing list mpiwg-sessions(a)lists.mpi-forum.org<mailto:[email protected]> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-sessions _______________________________________________ mpiwg-sessions mailing list mpiwg-sessions(a)lists.mpi-forum.org<mailto:[email protected]> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-sessions

1 0

Re: [mpiwg-sessions] meet today
by HOLMES Daniel 24 Apr '19

24 Apr '19

Hi Aurélien, I really need to get convinced that sessions, as the interface is proposed, is a first step in achieving new capabilities See, for example, Ralph’s response to this point. (beyond fixing the threaded initialization problem). Note: there are no other proposals that fix the threaded initialisation problem. This is not a trivial point. Even if sessions only provided a fix for this issue, it may still be worth providing this additional mechanism. Most of the thread-safety capabilities we are talking about, especially when hidden behind the request, can be achieved per-communicator with INFO keys, for example. Per-communicator scope is too fine-grained. Per-MPI process scope is too coarse-grained. Per-Session scope is just right (because its granularity is controllable). Also, the necessary INFO keys would break (or “selectively turn off” is less emotive) fundamental MPI semantics like the progress rule. Thus, in this case (and some others) sessions, as a concept, are not really improving on the state of the art, I disagree with this statement. or provide a more elegant interface to achieve the goal. Elegance is a subjective quality. I believe the proposed sessions interface is at least as elegant as many existing MPI interface design choices. I hope that helps clarify my objections, which are not that sessions 'cannot do it’, but more on the line that often ’communicators can do it equally well’. Communicators cannot do “it" equally well - without the help of several not-yet existing INFO keys (and even then it depends on what “it” is). Fixing the threaded initialisation problem cannot be done with communicator INFO keys. Associating several communicators with a set of resources and a common progress engine (different to other communicators) would need a sessions concept to be re-invented and specified via INFO keys. New INFO keys require additional standardisation effort in order to exist and to be as portable as the rest of the MPI Standard. Thus, for the foreseeable future (certainly as far as MPI-4 inclusive), communicators cannot do it equally well. Cheers, Dan. — Dr Daniel Holmes PhD Applications Consultant in HPC Research d.holmes(a)epcc.ed.ac.uk<mailto:[email protected]> Phone: +44 (0) 131 651 3465 Mobile: +44 (0) 7940 524 088 Address: Room 2.09, Bayes Centre, 47 Potterrow, Central Area, Edinburgh, EH8 9BT — The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. — On 23 Apr 2019, at 20:48, Aurelien Bouteiller <bouteill(a)icl.utk.edu<mailto:[email protected]>> wrote: Guys, unfortunately I couldn’t attend the latest telecon, but I have been following the discussion from a distance. I’ll take the time to review the minutes of latest meetings. Is there one in particular that is summarizing the discussion? Now my reticence is not only about thread levels. I really need to get convinced that sessions, as the interface is proposed, is a first step in achieving new capabilities (beyond fixing the threaded initialization problem). Most of the thread-safety capabilities we are talking about, especially when hidden behind the request, can be achieved with per-communicator with INFO keys, for example. Thus, in this case (and some others) sessions, as a concept, are not really improving on the state of the art, or provide a more elegant interface to achieve the goal. I hope that helps clarify my objections, which are not that sessions 'cannot do it’, but more on the line that often ’communicators can do it equally well’. Best, Aurelien On Apr 22, 2019, at 12:47, HOLMES Daniel via mpiwg-sessions <mpiwg-sessions(a)lists.mpi-forum.org<mailto:[email protected]>> wrote: Hi Howard, I’ll be there today. We need to figure out what our purpose is for the meeting on 24th April - or cancel our involvement. Martin added two for us so they existed but we don’t have to use the 2nd one if we have nothing new to present/ask/etc. Point of information: the "function pointers” group just decided today that explicit function pointers as part of the MPI user-facing interface, are not necessary for any of the use-cases for which they were proposed. Thus, we are likely not going to get function pointers + sessions any time ever. This is not a bad thing because one of those driving use-cases for function pointers was sessions - we convinced ourselves that the function pointers needed for sessions, e.g. to support different thread support levels, can be hidden behind the existing MPI functions and opaque handles. For example, the MPI_Request handle could lead to a function pointer for the actual “wait” function inside the MPI library and another for the actual “test” function. The MPI_WAIT and MPI_TEST functions will then be implemented as straightforward delegation shim functions that call down into the appropriate function pointer from the passed-in MPI_Request parameter. We should socialise that proposed approach with Aurelien (in particular) because he voted against sessions in the Chattanooga straw poll because of the perceived lack of support for multiple thread support levels in use at the same time. Cheers, Dan. — Dr Daniel Holmes PhD Applications Consultant in HPC Research d.holmes(a)epcc.ed.ac.uk<mailto:[email protected]> Phone: +44 (0) 131 651 3465 Mobile: +44 (0) 7940 524 088 Address: Room 2.09, Bayes Centre, 47 Potterrow, Central Area, Edinburgh, EH8 9BT — The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. — On 22 Apr 2019, at 17:16, Pritchard Jr., Howard via mpiwg-sessions <mpiwg-sessions(a)lists.mpi-forum.org<mailto:[email protected]>> wrote: HI Sessions activists, If possible, I’d like to meet today to discuss https://github.com/mpiwg-sessions/mpi-standard/pull/27 and https://github.com/mpiwg-sessions/mpi-standard/pull/26 as well as what to knock off next in https://github.com/mpiwg-sessions/sessions-issues/issues/10 Reminder we have an hour in the upcoming virtual forum on 4/24. Thanks, Howard -- Howard Pritchard HPC-ENV Los Alamos National Laboratory _______________________________________________ mpiwg-sessions mailing list mpiwg-sessions(a)lists.mpi-forum.org<mailto:[email protected]> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-sessions _______________________________________________ mpiwg-sessions mailing list mpiwg-sessions(a)lists.mpi-forum.org<mailto:[email protected]> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-sessions

1 0

Re: [mpiwg-sessions] meet today
by schulzm＠in.tum.de 24 Apr '19

24 Apr '19

Hi Ralph, all, I agree with the below and that we should support that use case. Sessions could indeed be a step in that direction, but something is missing for me in that: what would the process sets actually be and how would you identify communication partners?Also, how would you actually create the communicators in an asynchronous way - that part is still collective in the current proposal, which is a bit of an odd semantics for a “socket like” communication. Do you (asking in general, not necessarily only Ralph) have a concrete set of use cases to go for and how to support them? Thanks, Martin — Prof. Dr. Martin Schulz, Chair of Computer Architecture and Parallel Systems Department of Informatics, TU-Munich, Boltzmannstraße 3, D-85748 Garching Member of the Board of Directors at the Leibniz Supercomputing Centre (LRZ) Email: schulzm(a)in.tum.de > On 23. Apr 2019, at 19:49, Ralph H Castain via mpiwg-sessions <mpiwg-sessions(a)lists.mpi-forum.org> wrote: > > I cannot speak to the threading issue, but I can say that MPI Sessions is of greater interest than just that area. Specifically, non-traditional programming models are looking for MPI to adopt methods that support async formation and teardown of communicators so they can augment their models with MPI support. Sessions was of interest from that perspective, but if not embraced by the MPI Forum in the not-too-distant future, people will simply drop MPI and go forward with PMIx Groups combined with direct messaging via libfabric or suitable alternative. > > I think you all know I’m relatively neutral in the debate over programming models. I do fear, however, that MPI is making itself irrelevant by remaining stuck on static behaviors in an increasingly dynamic world. IMO, Sessions represents an interesting attempt to modernize the MPI programming model - I do hope it moves forward soon. > > Ralph > > >> On Apr 23, 2019, at 12:48 PM, Aurelien Bouteiller via mpiwg-sessions <mpiwg-sessions(a)lists.mpi-forum.org <mailto:[email protected]>> wrote: >> >> Guys, unfortunately I couldn’t attend the latest telecon, but I have been following the discussion from a distance. I’ll take the time to review the minutes of latest meetings. Is there one in particular that is summarizing the discussion? >> >> Now my reticence is not only about thread levels. I really need to get convinced that sessions, as the interface is proposed, is a first step in achieving new capabilities (beyond fixing the threaded initialization problem). Most of the thread-safety capabilities we are talking about, especially when hidden behind the request, can be achieved with per-communicator with INFO keys, for example. Thus, in this case (and some others) sessions, as a concept, are not really improving on the state of the art, or provide a more elegant interface to achieve the goal. I hope that helps clarify my objections, which are not that sessions 'cannot do it’, but more on the line that often ’communicators can do it equally well’. >> >> Best, >> Aurelien >> >>> On Apr 22, 2019, at 12:47, HOLMES Daniel via mpiwg-sessions <mpiwg-sessions(a)lists.mpi-forum.org <mailto:[email protected]>> wrote: >>> >>> Hi Howard, >>> >>> I’ll be there today. >>> >>> We need to figure out what our purpose is for the meeting on 24th April - or cancel our involvement. Martin added two for us so they existed but we don’t have to use the 2nd one if we have nothing new to present/ask/etc. >>> >>> Point of information: the "function pointers” group just decided today that explicit function pointers as part of the MPI user-facing interface, are not necessary for any of the use-cases for which they were proposed. Thus, we are likely not going to get function pointers + sessions any time ever. This is not a bad thing because one of those driving use-cases for function pointers was sessions - we convinced ourselves that the function pointers needed for sessions, e.g. to support different thread support levels, can be hidden behind the existing MPI functions and opaque handles. For example, the MPI_Request handle could lead to a function pointer for the actual “wait” function inside the MPI library and another for the actual “test” function. The MPI_WAIT and MPI_TEST functions will then be implemented as straightforward delegation shim functions that call down into the appropriate function pointer from the passed-in MPI_Request parameter. We should socialise that proposed approach with Aurelien (in particular) because he voted against sessions in the Chattanooga straw poll because of the perceived lack of support for multiple thread support levels in use at the same time. >>> >>> Cheers, >>> Dan. >>> — >>> Dr Daniel Holmes PhD >>> Applications Consultant in HPC Research >>> d.holmes(a)epcc.ed.ac.uk <mailto:[email protected]> >>> Phone: +44 (0) 131 651 3465 >>> Mobile: +44 (0) 7940 524 088 >>> Address: Room 2.09, Bayes Centre, 47 Potterrow, Central Area, Edinburgh, EH8 9BT >>> — >>> The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. >>> — >>> >>>> On 22 Apr 2019, at 17:16, Pritchard Jr., >>>> Howard via mpiwg-sessions <mpiwg-sessions(a)lists.mpi-forum.org <mailto:[email protected]>> wrote: >>>> >>>> HI Sessions activists, >>>> >>>> If possible, I’d like to meet today to discuss >>>> >>>> https://github.com/mpiwg-sessions/mpi-standard/pull/27 <https://github.com/mpiwg-sessions/mpi-standard/pull/27> >>>> and >>>> https://github.com/mpiwg-sessions/mpi-standard/pull/26 <https://github.com/mpiwg-sessions/mpi-standard/pull/26> >>>> >>>> as well as what to knock off next in >>>> >>>> https://github.com/mpiwg-sessions/sessions-issues/issues/10 <https://github.com/mpiwg-sessions/sessions-issues/issues/10> >>>> >>>> Reminder we have an hour in the upcoming virtual forum on 4/24. >>>> >>>> Thanks, >>>> >>>> Howard >>>> >>>> -- >>>> >>>> Howard Pritchard >>>> HPC-ENV >>>> Los Alamos National Laboratory >>>> >>>> _______________________________________________ >>>> mpiwg-sessions mailing list >>>> mpiwg-sessions(a)lists.mpi-forum.org <mailto:[email protected]> >>>> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-sessions <https://lists.mpi-forum.org/mailman/listinfo/mpiwg-sessions> >>> _______________________________________________ >>> mpiwg-sessions mailing list >>> mpiwg-sessions(a)lists.mpi-forum.org <mailto:[email protected]> >>> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-sessions <https://lists.mpi-forum.org/mailman/listinfo/mpiwg-sessions> >> >> _______________________________________________ >> mpiwg-sessions mailing list >> mpiwg-sessions(a)lists.mpi-forum.org <mailto:[email protected]> >> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-sessions > > _______________________________________________ > mpiwg-sessions mailing list > mpiwg-sessions(a)lists.mpi-forum.org > https://lists.mpi-forum.org/mailman/listinfo/mpiwg-sessions

1 0

Re: [mpiwg-sessions] meet today
by Ralph H Castain 23 Apr '19

23 Apr '19

I cannot speak to the threading issue, but I can say that MPI Sessions is of greater interest than just that area. Specifically, non-traditional programming models are looking for MPI to adopt methods that support async formation and teardown of communicators so they can augment their models with MPI support. Sessions was of interest from that perspective, but if not embraced by the MPI Forum in the not-too-distant future, people will simply drop MPI and go forward with PMIx Groups combined with direct messaging via libfabric or suitable alternative. I think you all know I’m relatively neutral in the debate over programming models. I do fear, however, that MPI is making itself irrelevant by remaining stuck on static behaviors in an increasingly dynamic world. IMO, Sessions represents an interesting attempt to modernize the MPI programming model - I do hope it moves forward soon. Ralph > On Apr 23, 2019, at 12:48 PM, Aurelien Bouteiller via mpiwg-sessions <mpiwg-sessions(a)lists.mpi-forum.org> wrote: > > Guys, unfortunately I couldn’t attend the latest telecon, but I have been following the discussion from a distance. I’ll take the time to review the minutes of latest meetings. Is there one in particular that is summarizing the discussion? > > Now my reticence is not only about thread levels. I really need to get convinced that sessions, as the interface is proposed, is a first step in achieving new capabilities (beyond fixing the threaded initialization problem). Most of the thread-safety capabilities we are talking about, especially when hidden behind the request, can be achieved with per-communicator with INFO keys, for example. Thus, in this case (and some others) sessions, as a concept, are not really improving on the state of the art, or provide a more elegant interface to achieve the goal. I hope that helps clarify my objections, which are not that sessions 'cannot do it’, but more on the line that often ’communicators can do it equally well’. > > Best, > Aurelien > >> On Apr 22, 2019, at 12:47, HOLMES Daniel via mpiwg-sessions <mpiwg-sessions(a)lists.mpi-forum.org <mailto:[email protected]>> wrote: >> >> Hi Howard, >> >> I’ll be there today. >> >> We need to figure out what our purpose is for the meeting on 24th April - or cancel our involvement. Martin added two for us so they existed but we don’t have to use the 2nd one if we have nothing new to present/ask/etc. >> >> Point of information: the "function pointers” group just decided today that explicit function pointers as part of the MPI user-facing interface, are not necessary for any of the use-cases for which they were proposed. Thus, we are likely not going to get function pointers + sessions any time ever. This is not a bad thing because one of those driving use-cases for function pointers was sessions - we convinced ourselves that the function pointers needed for sessions, e.g. to support different thread support levels, can be hidden behind the existing MPI functions and opaque handles. For example, the MPI_Request handle could lead to a function pointer for the actual “wait” function inside the MPI library and another for the actual “test” function. The MPI_WAIT and MPI_TEST functions will then be implemented as straightforward delegation shim functions that call down into the appropriate function pointer from the passed-in MPI_Request parameter. We should socialise that proposed approach with Aurelien (in particular) because he voted against sessions in the Chattanooga straw poll because of the perceived lack of support for multiple thread support levels in use at the same time. >> >> Cheers, >> Dan. >> — >> Dr Daniel Holmes PhD >> Applications Consultant in HPC Research >> d.holmes(a)epcc.ed.ac.uk <mailto:[email protected]> >> Phone: +44 (0) 131 651 3465 >> Mobile: +44 (0) 7940 524 088 >> Address: Room 2.09, Bayes Centre, 47 Potterrow, Central Area, Edinburgh, EH8 9BT >> — >> The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. >> — >> >>> On 22 Apr 2019, at 17:16, Pritchard Jr., >>> Howard via mpiwg-sessions <mpiwg-sessions(a)lists.mpi-forum.org <mailto:[email protected]>> wrote: >>> >>> HI Sessions activists, >>> >>> If possible, I’d like to meet today to discuss >>> >>> https://github.com/mpiwg-sessions/mpi-standard/pull/27 <https://github.com/mpiwg-sessions/mpi-standard/pull/27> >>> and >>> https://github.com/mpiwg-sessions/mpi-standard/pull/26 <https://github.com/mpiwg-sessions/mpi-standard/pull/26> >>> >>> as well as what to knock off next in >>> >>> https://github.com/mpiwg-sessions/sessions-issues/issues/10 <https://github.com/mpiwg-sessions/sessions-issues/issues/10> >>> >>> Reminder we have an hour in the upcoming virtual forum on 4/24. >>> >>> Thanks, >>> >>> Howard >>> >>> -- >>> >>> Howard Pritchard >>> HPC-ENV >>> Los Alamos National Laboratory >>> >>> _______________________________________________ >>> mpiwg-sessions mailing list >>> mpiwg-sessions(a)lists.mpi-forum.org <mailto:[email protected]> >>> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-sessions <https://lists.mpi-forum.org/mailman/listinfo/mpiwg-sessions> >> _______________________________________________ >> mpiwg-sessions mailing list >> mpiwg-sessions(a)lists.mpi-forum.org <mailto:[email protected]> >> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-sessions > > _______________________________________________ > mpiwg-sessions mailing list > mpiwg-sessions(a)lists.mpi-forum.org > https://lists.mpi-forum.org/mailman/listinfo/mpiwg-sessions

1 0

Re: [mpiwg-sessions] meet today
by Aurelien Bouteiller 23 Apr '19

23 Apr '19

Guys, unfortunately I couldn’t attend the latest telecon, but I have been following the discussion from a distance. I’ll take the time to review the minutes of latest meetings. Is there one in particular that is summarizing the discussion? Now my reticence is not only about thread levels. I really need to get convinced that sessions, as the interface is proposed, is a first step in achieving new capabilities (beyond fixing the threaded initialization problem). Most of the thread-safety capabilities we are talking about, especially when hidden behind the request, can be achieved with per-communicator with INFO keys, for example. Thus, in this case (and some others) sessions, as a concept, are not really improving on the state of the art, or provide a more elegant interface to achieve the goal. I hope that helps clarify my objections, which are not that sessions 'cannot do it’, but more on the line that often ’communicators can do it equally well’. Best, Aurelien > On Apr 22, 2019, at 12:47, HOLMES Daniel via mpiwg-sessions <mpiwg-sessions(a)lists.mpi-forum.org> wrote: > > Hi Howard, > > I’ll be there today. > > We need to figure out what our purpose is for the meeting on 24th April - or cancel our involvement. Martin added two for us so they existed but we don’t have to use the 2nd one if we have nothing new to present/ask/etc. > > Point of information: the "function pointers” group just decided today that explicit function pointers as part of the MPI user-facing interface, are not necessary for any of the use-cases for which they were proposed. Thus, we are likely not going to get function pointers + sessions any time ever. This is not a bad thing because one of those driving use-cases for function pointers was sessions - we convinced ourselves that the function pointers needed for sessions, e.g. to support different thread support levels, can be hidden behind the existing MPI functions and opaque handles. For example, the MPI_Request handle could lead to a function pointer for the actual “wait” function inside the MPI library and another for the actual “test” function. The MPI_WAIT and MPI_TEST functions will then be implemented as straightforward delegation shim functions that call down into the appropriate function pointer from the passed-in MPI_Request parameter. We should socialise that proposed approach with Aurelien (in particular) because he voted against sessions in the Chattanooga straw poll because of the perceived lack of support for multiple thread support levels in use at the same time. > > Cheers, > Dan. > — > Dr Daniel Holmes PhD > Applications Consultant in HPC Research > d.holmes(a)epcc.ed.ac.uk <mailto:[email protected]> > Phone: +44 (0) 131 651 3465 > Mobile: +44 (0) 7940 524 088 > Address: Room 2.09, Bayes Centre, 47 Potterrow, Central Area, Edinburgh, EH8 9BT > — > The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. > — > >> On 22 Apr 2019, at 17:16, Pritchard Jr., >> Howard via mpiwg-sessions <mpiwg-sessions(a)lists.mpi-forum.org <mailto:[email protected]>> wrote: >> >> HI Sessions activists, >> >> If possible, I’d like to meet today to discuss >> >> https://github.com/mpiwg-sessions/mpi-standard/pull/27 <https://github.com/mpiwg-sessions/mpi-standard/pull/27> >> and >> https://github.com/mpiwg-sessions/mpi-standard/pull/26 <https://github.com/mpiwg-sessions/mpi-standard/pull/26> >> >> as well as what to knock off next in >> >> https://github.com/mpiwg-sessions/sessions-issues/issues/10 <https://github.com/mpiwg-sessions/sessions-issues/issues/10> >> >> Reminder we have an hour in the upcoming virtual forum on 4/24. >> >> Thanks, >> >> Howard >> >> -- >> >> Howard Pritchard >> HPC-ENV >> Los Alamos National Laboratory >> >> _______________________________________________ >> mpiwg-sessions mailing list >> mpiwg-sessions(a)lists.mpi-forum.org <mailto:[email protected]> >> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-sessions <https://lists.mpi-forum.org/mailman/listinfo/mpiwg-sessions> > _______________________________________________ > mpiwg-sessions mailing list > mpiwg-sessions(a)lists.mpi-forum.org > https://lists.mpi-forum.org/mailman/listinfo/mpiwg-sessions

1 0

Re: [mpiwg-sessions] meet today
by HOLMES Daniel 22 Apr '19

22 Apr '19

Hi Howard, I’ll be there today. We need to figure out what our purpose is for the meeting on 24th April - or cancel our involvement. Martin added two for us so they existed but we don’t have to use the 2nd one if we have nothing new to present/ask/etc. Point of information: the "function pointers” group just decided today that explicit function pointers as part of the MPI user-facing interface, are not necessary for any of the use-cases for which they were proposed. Thus, we are likely not going to get function pointers + sessions any time ever. This is not a bad thing because one of those driving use-cases for function pointers was sessions - we convinced ourselves that the function pointers needed for sessions, e.g. to support different thread support levels, can be hidden behind the existing MPI functions and opaque handles. For example, the MPI_Request handle could lead to a function pointer for the actual “wait” function inside the MPI library and another for the actual “test” function. The MPI_WAIT and MPI_TEST functions will then be implemented as straightforward delegation shim functions that call down into the appropriate function pointer from the passed-in MPI_Request parameter. We should socialise that proposed approach with Aurelien (in particular) because he voted against sessions in the Chattanooga straw poll because of the perceived lack of support for multiple thread support levels in use at the same time. Cheers, Dan. — Dr Daniel Holmes PhD Applications Consultant in HPC Research d.holmes(a)epcc.ed.ac.uk<mailto:[email protected]> Phone: +44 (0) 131 651 3465 Mobile: +44 (0) 7940 524 088 Address: Room 2.09, Bayes Centre, 47 Potterrow, Central Area, Edinburgh, EH8 9BT — The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. — On 22 Apr 2019, at 17:16, Pritchard Jr., Howard via mpiwg-sessions <mpiwg-sessions(a)lists.mpi-forum.org<mailto:[email protected]>> wrote: HI Sessions activists, If possible, I’d like to meet today to discuss https://github.com/mpiwg-sessions/mpi-standard/pull/27 and https://github.com/mpiwg-sessions/mpi-standard/pull/26 as well as what to knock off next in https://github.com/mpiwg-sessions/sessions-issues/issues/10 Reminder we have an hour in the upcoming virtual forum on 4/24. Thanks, Howard -- Howard Pritchard HPC-ENV Los Alamos National Laboratory _______________________________________________ mpiwg-sessions mailing list mpiwg-sessions(a)lists.mpi-forum.org<mailto:[email protected]> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-sessions

1 0

meet today
by Pritchard Jr., Howard 22 Apr '19

22 Apr '19

HI Sessions activists, If possible, I’d like to meet today to discuss https://github.com/mpiwg-sessions/mpi-standard/pull/27 and https://github.com/mpiwg-sessions/mpi-standard/pull/26 as well as what to knock off next in https://github.com/mpiwg-sessions/sessions-issues/issues/10 Reminder we have an hour in the upcoming virtual forum on 4/24. Thanks, Howard -- Howard Pritchard HPC-ENV Los Alamos National Laboratory

1 0

cancel today's WG meeting
by Pritchard Jr., Howard 15 Apr '19

15 Apr '19

Hi Sessions WG folks, Dan is on holiday this week and Howard could use this time slot for Sessions related typing, so we will cancel today’s call. We’ll meet again next Monday. Howard -- Howard Pritchard B Schedule HPC-ENV Office 9, 2nd floor Research Park TA-03, Building 4200, Room 203 Los Alamos National Laboratory

1 0