[mpiwg-sessions] meet today

Wed Apr 24 05:08:45 CDT 2019

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 at epcc.ed.ac.uk<mailto:d.holmes at epcc.ed.ac.uk>
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 at icl.utk.edu<mailto:bouteill at icl.utk.edu>> 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 at lists.mpi-forum.org<mailto:mpiwg-sessions at 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 at epcc.ed.ac.uk<mailto:d.holmes at epcc.ed.ac.uk>
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 at lists.mpi-forum.org<mailto:mpiwg-sessions at lists.mpi-forum.org>> 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 at lists.mpi-forum.org<mailto:mpiwg-sessions at lists.mpi-forum.org>
https://lists.mpi-forum.org/mailman/listinfo/mpiwg-sessions

_______________________________________________
mpiwg-sessions mailing list
mpiwg-sessions at lists.mpi-forum.org<mailto:mpiwg-sessions at lists.mpi-forum.org>
https://lists.mpi-forum.org/mailman/listinfo/mpiwg-sessions

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-sessions/attachments/20190424/f4dfd33e/attachment-0001.html>