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: [email protected]

On 23. Apr 2019, at 19:49, Ralph H Castain via mpiwg-sessions <[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 <[email protected] <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 <[email protected] <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 [email protected] <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 <[email protected] <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 [email protected] <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 [email protected] <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 [email protected] <mailto:[email protected]> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-sessions

_______________________________________________ mpiwg-sessions mailing list [email protected] https://lists.mpi-forum.org/mailman/listinfo/mpiwg-sessions