[mpiwg-sessions] Final comments on last tweaks for MPI Sessions

Fri Oct 4 10:19:57 CDT 2019

HI Martin,

Duh, sorry I was working with my local copy of the topic branch and hadn’t sync’d with the additional commits Dan had put on my branch on github.  Should be fixed up now.

Howard

From: "schulzm at in.tum.de" <schulzm at in.tum.de>
Date: Tuesday, October 1, 2019 at 4:29 PM
To: "Pritchard Jr., Howard" <howardp at lanl.gov>
Cc: HOLMES Daniel <d.holmes at epcc.ed.ac.uk>, MPI Sessions working group <mpiwg-sessions at lists.mpi-forum.org>
Subject: Re: Final comments on last tweaks for MPI Sessions

Hi Howard,

I cloned the repo today and it says it is at 3f6738d.

As for tomorrow, do you mean the virtual meeting or another one? We haven’t scheduled the virtual meeting, yet, but we could certainly use the time for it.

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 at in.tum.de<mailto:schulzm at in.tum.de>

On 1. Oct 2019, at 23:44, Pritchard Jr., Howard <howardp at lanl.gov<mailto:howardp at lanl.gov>> wrote:

Hi Martin,

This is quite odd about the compilation problem, I’m not seeing it.  I’m at a05c39a0.

Okay, we could rework the string return to be like the fixed info string handling.

Good point about the thread level.  I’ll add that to the pset branch unless I here otherwise from Dan before the meeting tomorrow.

Howard

From: "schulzm at in.tum.de<mailto:schulzm at in.tum.de>" <schulzm at in.tum.de<mailto:schulzm at in.tum.de>>
Date: Tuesday, October 1, 2019 at 3:31 PM
To: "Pritchard Jr., Howard" <howardp at lanl.gov<mailto:howardp at lanl.gov>>
Cc: HOLMES Daniel <d.holmes at epcc.ed.ac.uk<mailto:d.holmes at epcc.ed.ac.uk>>, MPI Sessions working group <mpiwg-sessions at lists.mpi-forum.org<mailto:mpiwg-sessions at lists.mpi-forum.org>>
Subject: Re: Final comments on last tweaks for MPI Sessions

Hi Howard,

Re: compilation problem - I cloned your topic/adding_psets branch, as this was referenced in Dan’s email.

Re: string return - isn’t that too late? We would have to change functions prototypes after the 1st vote, which is not ideal. I think the forum gave a pretty clear guidance on this last time - wouldn’t it be better to change this right away or at least have both versions ready?

Re: default thread level - yes, missed that - thanks.  Would it make sense to specify that the default level cannot be MPI_THREAD_SINGLE unless that MPI only supports MPI_THREAD_SINGLE? Ot at least add an advice to implementors in that direction?

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 at in.tum.de<mailto:schulzm at in.tum.de>

On 1. Oct 2019, at 22:00, Pritchard Jr., Howard <howardp at lanl.gov<mailto:howardp at lanl.gov>> wrote:

HI Martin,

Thanks, responses interleaved below

From: "schulzm at in.tum.de<mailto:schulzm at in.tum.de>" <schulzm at in.tum.de<mailto:schulzm at in.tum.de>>
Date: Tuesday, October 1, 2019 at 1:15 PM
To: HOLMES Daniel <d.holmes at epcc.ed.ac.uk<mailto:d.holmes at epcc.ed.ac.uk>>
Cc: MPI Sessions working group <mpiwg-sessions at lists.mpi-forum.org<mailto:mpiwg-sessions at lists.mpi-forum.org>>, "Pritchard Jr., Howard" <howardp at lanl.gov<mailto:howardp at lanl.gov>>
Subject: Re: Final comments on last tweaks for MPI Sessions

Hi Dan, Howard, all,

I finally had a chance to look over the latest changes and generally this is looking good to me, but I have a few more comments:

First a detail that I came across when trying to build
- dynamic-2.tex, line 964: Misses an \ before the _ in MPI_Comm to build

I’m not seeing this when I try to build the tex at mpiwg-sessions:RearrangeInitialisationTextForSessions

Regarding PSETs:
- Text at MPI_SESSION_GET_NUM_PSETS
I think this works
- Text at MPI_SESSION_GET_NTH_PSETLEN
This may raise concerns (I would have to agree), as this is the old style of returning strings and we just decided to fix the info string text with a new way to return text. Also, if we do want to make names mutable at some point, then this would not be thread safe. Using the INOUT option for length argument would be better.
Right, we will update if the info proposal gets accepted into the standard.

- Text at MPI_SESSION_GET_NTH_PSET
I think we need a similar text here as in the MP_T chapter:

After a successful call to MPI_T_CVAR_GET_INFO for a particular variable, subsequent calls to this routine that query information about the same variable must return the same information. An MPI implementation is not allowed to alter any of the returned values.

Only this ensures that process sets are not “replaced” by the implementation and a user can cache data.

Good idea to add this.

Set versioning:

One other concern that I have, but I am not sure how to properly address it, so I want to just throw it out: I think we will have to have some option for versioning sets - only this will prevent a blow up in sets that we have to remember once we go to dynamic sets. In this case, an MPI implementation would only have to report data for the latest set and hence could replace sets. I know we don’t want to deal with this now and we are also not sure, if this is the right answer, but it would be nice to add something that allow us to do this later. Adding a real version argument is probably too vague at the moment, but what about adding a - currently unused - info object in the PSET query function? Another option would be to reserve a character in the URI that right now can’t be used, but later can be used as a delimiter.

I like the info object idea for indicating versions.

In general, shouldn’t we specify the URI format more? In this case, the “:” would already be such a delimiter.

Other comments:
- What is the default thread level when no info object is specified?
We decided to add a sentence  about that.  See last sentence around the description of the thread_support_level key.

- MPI_Session_finalize, "it must locally complete all MPI operations that it initiated” needs to be restricted to all communication associated with the session, other sessions should be unaffected
Good point.
- 10.3.2: A process set caches key/value tuples which -> that

One other thing that I noticed:
- Section 10.10.2 - I think this text needs to be updated as well to include the use of Sessions
Good point too.  We’ll add a blurb about becoming an MPI process the sessions way.

If you want to go through this tomorrow on the virtual meeting, I would be available.

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 at in.tum.de<mailto:schulzm at in.tum.de>

On 30. Sep 2019, at 14:00, HOLMES Daniel <d.holmes at epcc.ed.ac.uk<mailto:d.holmes at epcc.ed.ac.uk>> wrote:

Hi Martin,

Do you have comments on the tweaked wording about psets for the sessions proposal?

The new text, incorporating feedback from the virtual meeting, can be found here:
https://github.com/mpiwg-sessions/mpi-standard/pull/37
(You should already have access to this because you are a member of that Github organisation.)

We have no other topics for our WG telecon this afternoon. In the absence of additional comments, we will cancel today’s meeting and give up our priority slot for this week’s virtual meeting.

Cheers,
Dan.
—
Dr Daniel Holmes PhD
Architect (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.
—

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