[mpiwg-sessions] meet today

Tue Apr 23 21:49:57 CDT 2019

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 at 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 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 <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 at lists.mpi-forum.org <mailto:mpiwg-sessions at lists.mpi-forum.org>
>>> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-sessions <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
> 
> _______________________________________________
> mpiwg-sessions mailing list
> 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/20190423/3e7fa4e8/attachment-0001.html>