October 2019 - mpiwg-sessions - mailman3.cels.anl.gov

Re: [mpiwg-sessions] [mpiwg-sessions/mpi-standard] sessions: add another sentence about adding psets, etc. (#37)
by HOLMES Daniel 16 Oct '19

16 Oct '19

Hi Thomas, Thanks for the minor tweaks. I’ve reviewed them and made comments on your PR. Cheers, Dan. — Dr Daniel Holmes PhD Architect (HPC Research) d.holmes(a)epcc.ed.ac.uk<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 16 Oct 2019, at 17:06, Thomas Naughton <notifications(a)github.com<mailto:[email protected]>> wrote: @dholmes-epcc-ed-ac-uk<https://github.com/dholmes-epcc-ed-ac-uk> After second thought, the few typos I saw are not in the change set for this specific ticket (i.e., not in the diff). So I will open a separate PR against mpiwg-sessions:RearrangeInitialisationTextForSessions with the few typos I noticed for easy review/merge. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<https://github.com/mpiwg-sessions/mpi-standard/pull/37?email_source=notific…>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ADD7YSUUDSRPTJ4MBE63MN3QO…>.

1 0

Re: [mpiwg-sessions] Final comments on last tweaks for MPI Sessions
by Pritchard Jr., Howard 06 Oct '19

06 Oct '19

Hi Martin, I pushed fixes to the PR branch: git checkout -b hppritcha-topic/adding_psets RearrangeInitialisationTextForSessions git pull [email protected]:hppritcha/mpi-standard.git topic/adding_psets the build fix is in 4590cbae6480943598a220ea6bee0266c989b545 Howard From: "schulzm(a)in.tum.de" <schulzm(a)in.tum.de> Date: Sunday, October 6, 2019 at 6:57 PM To: "Pritchard Jr., Howard" <howardp(a)lanl.gov> Cc: HOLMES Daniel <d.holmes(a)epcc.ed.ac.uk>, MPI Sessions working group <mpiwg-sessions(a)lists.mpi-forum.org> Subject: Re: Final comments on last tweaks for MPI Sessions Hi Howard, No problem - I’ll take another look at the current version. Can you please send me the exact version/branch/repo I should look at, to make sure I get it right? 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(a)in.tum.de<mailto:[email protected]> On 4. Oct 2019, at 17:19, Pritchard Jr., Howard <howardp(a)lanl.gov<mailto:[email protected]>> wrote: 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(a)in.tum.de<mailto:[email protected]>" <schulzm(a)in.tum.de<mailto:[email protected]>> Date: Tuesday, October 1, 2019 at 4:29 PM To: "Pritchard Jr., Howard" <howardp(a)lanl.gov<mailto:[email protected]>> Cc: HOLMES Daniel <d.holmes(a)epcc.ed.ac.uk<mailto:[email protected]>>, MPI Sessions working group <mpiwg-sessions(a)lists.mpi-forum.org<mailto:[email protected]>> 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(a)in.tum.de<mailto:[email protected]> On 1. Oct 2019, at 23:44, Pritchard Jr., Howard <howardp(a)lanl.gov<mailto:[email protected]>> 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(a)in.tum.de<mailto:[email protected]>" <schulzm(a)in.tum.de<mailto:[email protected]>> Date: Tuesday, October 1, 2019 at 3:31 PM To: "Pritchard Jr., Howard" <howardp(a)lanl.gov<mailto:[email protected]>> Cc: HOLMES Daniel <d.holmes(a)epcc.ed.ac.uk<mailto:[email protected]>>, MPI Sessions working group <mpiwg-sessions(a)lists.mpi-forum.org<mailto:[email protected]>> 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(a)in.tum.de<mailto:[email protected]> On 1. Oct 2019, at 22:00, Pritchard Jr., Howard <howardp(a)lanl.gov<mailto:[email protected]>> wrote: HI Martin, Thanks, responses interleaved below From: "schulzm(a)in.tum.de<mailto:[email protected]>" <schulzm(a)in.tum.de<mailto:[email protected]>> Date: Tuesday, October 1, 2019 at 1:15 PM To: HOLMES Daniel <d.holmes(a)epcc.ed.ac.uk<mailto:[email protected]>> Cc: MPI Sessions working group <mpiwg-sessions(a)lists.mpi-forum.org<mailto:[email protected]>>, "Pritchard Jr., Howard" <howardp(a)lanl.gov<mailto:[email protected]>> 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(a)in.tum.de<mailto:[email protected]> On 30. Sep 2019, at 14:00, HOLMES Daniel <d.holmes(a)epcc.ed.ac.uk<mailto:[email protected]>> 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(a)epcc.ed.ac.uk<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. —

1 0

Re: [mpiwg-sessions] Final comments on last tweaks for MPI Sessions
by schulzm＠in.tum.de 06 Oct '19

06 Oct '19

Hi Howard, No problem - I’ll take another look at the current version. Can you please send me the exact version/branch/repo I should look at, to make sure I get it right? 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(a)in.tum.de > On 4. Oct 2019, at 17:19, Pritchard Jr., Howard <howardp(a)lanl.gov> wrote: > > 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(a)in.tum.de" <schulzm(a)in.tum.de> > Date: Tuesday, October 1, 2019 at 4:29 PM > To: "Pritchard Jr., Howard" <howardp(a)lanl.gov> > Cc: HOLMES Daniel <d.holmes(a)epcc.ed.ac.uk>, MPI Sessions working group <mpiwg-sessions(a)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(a)in.tum.de <mailto:[email protected]> > > > > > > > > > >> On 1. Oct 2019, at 23:44, Pritchard Jr., Howard <howardp(a)lanl.gov <mailto:[email protected]>> 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(a)in.tum.de <mailto:[email protected]>" <schulzm(a)in.tum.de <mailto:[email protected]>> >> Date: Tuesday, October 1, 2019 at 3:31 PM >> To: "Pritchard Jr., Howard" <howardp(a)lanl.gov <mailto:[email protected]>> >> Cc: HOLMES Daniel <d.holmes(a)epcc.ed.ac.uk <mailto:[email protected]>>, MPI Sessions working group <mpiwg-sessions(a)lists.mpi-forum.org <mailto:[email protected]>> >> 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(a)in.tum.de <mailto:[email protected]> >> >> >> >> >> >> >> >> >> >> >>> On 1. Oct 2019, at 22:00, Pritchard Jr., Howard <howardp(a)lanl.gov <mailto:[email protected]>> wrote: >>> >>> HI Martin, >>> >>> Thanks, responses interleaved below >>> >>> From: "schulzm(a)in.tum.de <mailto:[email protected]>" <schulzm(a)in.tum.de <mailto:[email protected]>> >>> Date: Tuesday, October 1, 2019 at 1:15 PM >>> To: HOLMES Daniel <d.holmes(a)epcc.ed.ac.uk <mailto:[email protected]>> >>> Cc: MPI Sessions working group <mpiwg-sessions(a)lists.mpi-forum.org <mailto:[email protected]>>, "Pritchard Jr., Howard" <howardp(a)lanl.gov <mailto:[email protected]>> >>> 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(a)in.tum.de <mailto:[email protected]> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>>> On 30. Sep 2019, at 14:00, HOLMES Daniel <d.holmes(a)epcc.ed.ac.uk <mailto:[email protected]>> 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 <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(a)epcc.ed.ac.uk <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. >>>> —

1 0

Re: [mpiwg-sessions] Final comments on last tweaks for MPI Sessions
by Pritchard Jr., Howard 04 Oct '19

04 Oct '19

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(a)in.tum.de" <schulzm(a)in.tum.de> Date: Tuesday, October 1, 2019 at 4:29 PM To: "Pritchard Jr., Howard" <howardp(a)lanl.gov> Cc: HOLMES Daniel <d.holmes(a)epcc.ed.ac.uk>, MPI Sessions working group <mpiwg-sessions(a)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(a)in.tum.de<mailto:[email protected]> On 1. Oct 2019, at 23:44, Pritchard Jr., Howard <howardp(a)lanl.gov<mailto:[email protected]>> 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(a)in.tum.de<mailto:[email protected]>" <schulzm(a)in.tum.de<mailto:[email protected]>> Date: Tuesday, October 1, 2019 at 3:31 PM To: "Pritchard Jr., Howard" <howardp(a)lanl.gov<mailto:[email protected]>> Cc: HOLMES Daniel <d.holmes(a)epcc.ed.ac.uk<mailto:[email protected]>>, MPI Sessions working group <mpiwg-sessions(a)lists.mpi-forum.org<mailto:[email protected]>> 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(a)in.tum.de<mailto:[email protected]> On 1. Oct 2019, at 22:00, Pritchard Jr., Howard <howardp(a)lanl.gov<mailto:[email protected]>> wrote: HI Martin, Thanks, responses interleaved below From: "schulzm(a)in.tum.de<mailto:[email protected]>" <schulzm(a)in.tum.de<mailto:[email protected]>> Date: Tuesday, October 1, 2019 at 1:15 PM To: HOLMES Daniel <d.holmes(a)epcc.ed.ac.uk<mailto:[email protected]>> Cc: MPI Sessions working group <mpiwg-sessions(a)lists.mpi-forum.org<mailto:[email protected]>>, "Pritchard Jr., Howard" <howardp(a)lanl.gov<mailto:[email protected]>> 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(a)in.tum.de<mailto:[email protected]> On 30. Sep 2019, at 14:00, HOLMES Daniel <d.holmes(a)epcc.ed.ac.uk<mailto:[email protected]>> 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(a)epcc.ed.ac.uk<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. —

1 0

Re: [mpiwg-sessions] Final comments on last tweaks for MPI Sessions
by Pritchard Jr., Howard 01 Oct '19

01 Oct '19

Hi Martin, Never mind I was confused about the schedule. Howard From: "schulzm(a)in.tum.de" <schulzm(a)in.tum.de> Date: Tuesday, October 1, 2019 at 4:29 PM To: "Pritchard Jr., Howard" <howardp(a)lanl.gov> Cc: HOLMES Daniel <d.holmes(a)epcc.ed.ac.uk>, MPI Sessions working group <mpiwg-sessions(a)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(a)in.tum.de<mailto:[email protected]> On 1. Oct 2019, at 23:44, Pritchard Jr., Howard <howardp(a)lanl.gov<mailto:[email protected]>> 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(a)in.tum.de<mailto:[email protected]>" <schulzm(a)in.tum.de<mailto:[email protected]>> Date: Tuesday, October 1, 2019 at 3:31 PM To: "Pritchard Jr., Howard" <howardp(a)lanl.gov<mailto:[email protected]>> Cc: HOLMES Daniel <d.holmes(a)epcc.ed.ac.uk<mailto:[email protected]>>, MPI Sessions working group <mpiwg-sessions(a)lists.mpi-forum.org<mailto:[email protected]>> 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(a)in.tum.de<mailto:[email protected]> On 1. Oct 2019, at 22:00, Pritchard Jr., Howard <howardp(a)lanl.gov<mailto:[email protected]>> wrote: HI Martin, Thanks, responses interleaved below From: "schulzm(a)in.tum.de<mailto:[email protected]>" <schulzm(a)in.tum.de<mailto:[email protected]>> Date: Tuesday, October 1, 2019 at 1:15 PM To: HOLMES Daniel <d.holmes(a)epcc.ed.ac.uk<mailto:[email protected]>> Cc: MPI Sessions working group <mpiwg-sessions(a)lists.mpi-forum.org<mailto:[email protected]>>, "Pritchard Jr., Howard" <howardp(a)lanl.gov<mailto:[email protected]>> 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(a)in.tum.de<mailto:[email protected]> On 30. Sep 2019, at 14:00, HOLMES Daniel <d.holmes(a)epcc.ed.ac.uk<mailto:[email protected]>> 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(a)epcc.ed.ac.uk<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. —

1 0

Re: [mpiwg-sessions] Final comments on last tweaks for MPI Sessions
by schulzm＠in.tum.de 01 Oct '19

01 Oct '19

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(a)in.tum.de > On 1. Oct 2019, at 23:44, Pritchard Jr., Howard <howardp(a)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(a)in.tum.de <mailto:[email protected]>" <schulzm(a)in.tum.de <mailto:[email protected]>> > Date: Tuesday, October 1, 2019 at 3:31 PM > To: "Pritchard Jr., Howard" <howardp(a)lanl.gov <mailto:[email protected]>> > Cc: HOLMES Daniel <d.holmes(a)epcc.ed.ac.uk <mailto:[email protected]>>, MPI Sessions working group <mpiwg-sessions(a)lists.mpi-forum.org <mailto:[email protected]>> > 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(a)in.tum.de <mailto:[email protected]> > > > > > > > > > >> On 1. Oct 2019, at 22:00, Pritchard Jr., Howard <howardp(a)lanl.gov <mailto:[email protected]>> wrote: >> >> HI Martin, >> >> Thanks, responses interleaved below >> >> From: "schulzm(a)in.tum.de <mailto:[email protected]>" <schulzm(a)in.tum.de <mailto:[email protected]>> >> Date: Tuesday, October 1, 2019 at 1:15 PM >> To: HOLMES Daniel <d.holmes(a)epcc.ed.ac.uk <mailto:[email protected]>> >> Cc: MPI Sessions working group <mpiwg-sessions(a)lists.mpi-forum.org <mailto:[email protected]>>, "Pritchard Jr., Howard" <howardp(a)lanl.gov <mailto:[email protected]>> >> 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(a)in.tum.de <mailto:[email protected]> >> >> >> >> >> >> >> >> >> >> >>> On 30. Sep 2019, at 14:00, HOLMES Daniel <d.holmes(a)epcc.ed.ac.uk <mailto:[email protected]>> 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 <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(a)epcc.ed.ac.uk <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. >>> —

1 0

Re: [mpiwg-sessions] Final comments on last tweaks for MPI Sessions
by Pritchard Jr., Howard 01 Oct '19

01 Oct '19

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(a)in.tum.de" <schulzm(a)in.tum.de> Date: Tuesday, October 1, 2019 at 3:31 PM To: "Pritchard Jr., Howard" <howardp(a)lanl.gov> Cc: HOLMES Daniel <d.holmes(a)epcc.ed.ac.uk>, MPI Sessions working group <mpiwg-sessions(a)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(a)in.tum.de<mailto:[email protected]> On 1. Oct 2019, at 22:00, Pritchard Jr., Howard <howardp(a)lanl.gov<mailto:[email protected]>> wrote: HI Martin, Thanks, responses interleaved below From: "schulzm(a)in.tum.de<mailto:[email protected]>" <schulzm(a)in.tum.de<mailto:[email protected]>> Date: Tuesday, October 1, 2019 at 1:15 PM To: HOLMES Daniel <d.holmes(a)epcc.ed.ac.uk<mailto:[email protected]>> Cc: MPI Sessions working group <mpiwg-sessions(a)lists.mpi-forum.org<mailto:[email protected]>>, "Pritchard Jr., Howard" <howardp(a)lanl.gov<mailto:[email protected]>> 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(a)in.tum.de<mailto:[email protected]> On 30. Sep 2019, at 14:00, HOLMES Daniel <d.holmes(a)epcc.ed.ac.uk<mailto:[email protected]>> 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(a)epcc.ed.ac.uk<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. —

1 0

Re: [mpiwg-sessions] Final comments on last tweaks for MPI Sessions
by schulzm＠in.tum.de 01 Oct '19

01 Oct '19

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(a)in.tum.de > On 1. Oct 2019, at 22:00, Pritchard Jr., Howard <howardp(a)lanl.gov> wrote: > > HI Martin, > > Thanks, responses interleaved below > > From: "schulzm(a)in.tum.de <mailto:[email protected]>" <schulzm(a)in.tum.de <mailto:[email protected]>> > Date: Tuesday, October 1, 2019 at 1:15 PM > To: HOLMES Daniel <d.holmes(a)epcc.ed.ac.uk <mailto:[email protected]>> > Cc: MPI Sessions working group <mpiwg-sessions(a)lists.mpi-forum.org <mailto:[email protected]>>, "Pritchard Jr., Howard" <howardp(a)lanl.gov <mailto:[email protected]>> > 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(a)in.tum.de <mailto:[email protected]> > > > > > > > > > >> On 30. Sep 2019, at 14:00, HOLMES Daniel <d.holmes(a)epcc.ed.ac.uk <mailto:[email protected]>> 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 <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(a)epcc.ed.ac.uk <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. >> — >> > >

1 0

Re: [mpiwg-sessions] Final comments on last tweaks for MPI Sessions
by Pritchard Jr., Howard 01 Oct '19

01 Oct '19

HI Martin, Thanks, responses interleaved below From: "schulzm(a)in.tum.de" <schulzm(a)in.tum.de> Date: Tuesday, October 1, 2019 at 1:15 PM To: HOLMES Daniel <d.holmes(a)epcc.ed.ac.uk> Cc: MPI Sessions working group <mpiwg-sessions(a)lists.mpi-forum.org>, "Pritchard Jr., Howard" <howardp(a)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(a)in.tum.de<mailto:[email protected]> On 30. Sep 2019, at 14:00, HOLMES Daniel <d.holmes(a)epcc.ed.ac.uk<mailto:[email protected]>> 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(a)epcc.ed.ac.uk<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. —

1 0

Re: [mpiwg-sessions] Final comments on last tweaks for MPI Sessions
by schulzm＠in.tum.de 01 Oct '19

01 Oct '19

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 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. - 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. 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. 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? - 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 - 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 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(a)in.tum.de > On 30. Sep 2019, at 14:00, HOLMES Daniel <d.holmes(a)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 <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(a)epcc.ed.ac.uk <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. > — >

1 0