[mpiwg-sessions] Minutes for MPI Session meeting with special guest Rolf

[Martin SCHREIBER]

Hi all,

we intensively discussed (thanks Rolf!) the different options for the
changes in the MPI standard and I thought it's good to send this around
as minutes.

Attendees (until the end): Joseph, Rolf, Dominik, Martin (Schreiber)

I’m trying to summarize it here:

First of all, there’s an alternative A and B:
================================

* Alternative A: Changing MPI Sessions (starting/finishing) might lead
to non-optimal utilization of MPI derived data types. This would be
communicated to the implementors and they are supposed to fix.

** Obviously, this puts more effort for the implementors to get it
done.

** We discussed the realization of this. There have been some thoughts
that this would lead to overheads each time a communication is done to
check for this, but then came to the conclusion that these overheads
are always required: Data Types are defined without being specific to
communicators. Hence, they need to be optimized in an lazy way or a-
priory (or something in between). As a consequence, there would be
always overheads and we don’t expect any additional overheads for this
option A.

** This also follows the main principle of the MPI implementation to be
easy usable.


* Alternative B: Derived data types might not be optimal anymore after
changing MPI Sessions.

** This would put a lot of burden on the users.

** In particular, it’s not clear how to “recommit” datatypes in order
to optimize this.

** Users don't want to live with the situation that data types might
suddenly be less efficiently usable.


=> We (Rolf, Joseph, Dominik & Martin) all agreed to "Alternative A"
(which doesn't mean that this is final)



The second issue is about "with or without option C":
================================

* With option C:

** Requires users to care about everything on their own to free
handlers at finalize.

** This breaks with libraries / tools to easily switch to sessions.


* Without option C:

** There would be just a recommendation to users to free handlers
explicitly.

** This recommendation could be incentivize by tools such as MUST
(pointing out the user that with Sessions, the handles, etc. should be
freed).


=> We all agreed that without option C would be the best solution.
Again, this is just our opinion and shouldn't be seen as a final
decision (unless you all agree).


All the best,

Martin & the others



-- 
Prof. Dr. Martin Schreiber

Applied Mathematics | High Perf. Scientific Comp. for PDEs
Université Grenoble Alpes | Lab. Jean Kuntzmann | INRIA, France

For Time-X Euro-HPC project:
TUM School of CIT, Technical University of Munich, Germany