- mpiwg-p2p - mailman3.cels.anl.gov

Re: [mpiwg-p2p] Result of reading of Info Query #63
by Rolf Rabenseifner 02 Mar '17

02 Mar '17

I did not follow the discussion, but I want to remember (for the case that some are not aware of) that MPI_File_get_info returns not what the user set. It returns all used info, system-specific infos plus those set by the user that are not ignored. This works fine with all the parallel file-systems and their system-specific (i.e., non-user supplied?) values. And of course, the user can learn from that and change those values with MPI_File_set_info. The wording for MPI_Win_get_info and MPI_Comm_get_info is the same. See MPI-3.1, Sect. 6.4.4, page 250, lines 9-13, Advice to users. (Same on page 502, lines 1-5) And other wording in Sect. 11.2.7, page 415-416, lines 47ff, Adv. to impl. Rolf ----- Original Message ----- > From: "Daniel Holmes" <dholmes(a)epcc.ed.ac.uk> > To: "MPI WG Point To Point Communications working group" <mpiwg-p2p(a)lists.mpi-forum.org> > Sent: Wednesday, March 1, 2017 11:58:28 PM > Subject: [mpiwg-p2p] Result of reading of Info Query #63 > Exec summary > > The MPI_XXX_GET_INFO text is acceptable to everyone as is. > > The MPI_XXX_SET_INFO text is contentious for two reasons: > 1) (lack of) ability for MPI to pick non-user supplied values. Pavan brought > this up. Resolution: none. Suggestions: continue arguing against this or add > additional MPI_XXX_SET_INFO_INEXACT (or similar), which allows randomness - > lets user choose. > 2) (lack of) transactional behaviour - all key/value updates should succeed or > all should fail. Martin brought this up. Resolution: this is a new API, we’d > love to see your proposal. > > Cheers, > Dan. > -- > The University of Edinburgh is a charitable body, registered in > Scotland, with registration number SC005336. > > _______________________________________________ > mpiwg-p2p mailing list > mpiwg-p2p(a)lists.mpi-forum.org > https://lists.mpi-forum.org/mailman/listinfo/mpiwg-p2p -- Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307)

1 0

Result of reading of Info Query #63
by Dan Holmes 01 Mar '17

01 Mar '17

Exec summary The MPI_XXX_GET_INFO text is acceptable to everyone as is. The MPI_XXX_SET_INFO text is contentious for two reasons: 1) (lack of) ability for MPI to pick non-user supplied values. Pavan brought this up. Resolution: none. Suggestions: continue arguing against this or add additional MPI_XXX_SET_INFO_INEXACT (or similar), which allows randomness - lets user choose. 2) (lack of) transactional behaviour - all key/value updates should succeed or all should fail. Martin brought this up. Resolution: this is a new API, we’d love to see your proposal. Cheers, Dan. -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

1 0

Get/Set Info Review Today
by Jim Dinan 13 Feb '17

13 Feb '17

Hi All, Today is the two-week deadline for the upcoming meeting. We'll do a final review of the revised proposal at today's meeting before posting it for a formal reading. ~Jim.

1 0

Re: [mpiwg-p2p] Get/Set Info Update
by Jim Dinan 30 Jan '17

30 Jan '17

Hi All, I would like to use today's meeting (coming up in 1 hour at 11am CT) to review the new text that I sent out earlier. Connection info is on the wiki: https://github.com/mpiwg-p2p/p2p-issues/wiki ~Jim. On Mon, Jan 23, 2017 at 5:22 PM, Jim Dinan <james.dinan(a)gmail.com> wrote: > Hi All, > > I made a first attempt at updating the get/set info text with the feedback > from the December meeting. For starters, I'm working with just the > communicator get/set info text, so please ignore RMA and I/O for now. For > the previous draft of the proposal, please refer to the PDF posted under > "references" on the issue page (https://github.com/mpi-forum/ > mpi-issues/issues/63) or the existing PR. > > I pushed the changes to a work-in-progress branch, in case anyone would > like to see the history (https://github.com/mpiwg-p2p/ > mpi-standard/tree/wip/get-info). You can also compare with the main > spec: https://github.com/mpi-forum/mpi-standard/compare/ > mpi-3.x...mpiwg-p2p:wip/get-info?expand=1 > > Here's the to-do list I captured from the last meeting: > > 1. Remove info key deletion by omission in calls to set_info (breaks > existing semantic) > 2. Allow get_info to return keys not set by the user (e.g. "filename" > info key) > 3. Should get_info return all info keys supported by the implementation? > > I took a whack at #1 and #2. I'm still thinking about how to handle info > keys that don't have good defaults (e.g. "filename") and whether #3 is a > good idea. Anyway, without further ado, here is the updated text: > > MPI_COMM_SET_INFO: > > \mpifunc{MPI\_COMM\_SET\_INFO} updates the hints of the > communicator associated with > \mpiarg{comm} using the hints provided in \mpiarg{info}. > > \mpifunc{MPI\_COMM\_SET\_INFO} is a collective > > routine. The info object may be different on each process, but any > > info entries that an implementation requires to be the same on all > > processes must appear with the same value in each process's info > object. > > \begin{users} > Some info items that an implementation can use when it creates a > > communicator cannot easily be changed once the communicator has been > created. Thus, an implementation may ignore hints issued in this call > that it would have accepted in a creation call. > > % > An implementation may also be unable to update certain info hints once > set. > % > \mpifunc{MPI\_COMM\_GET\_INFO} can be used to determine whether updates > to existing info hints were ignored by the implementation. > > \end{users} > > MPI_COMM_GET_INFO: > > \mpifunc{MPI\_COMM\_GET\_INFO} returns a new info object containing > the hints of the communicator associated with \mpiarg{comm}. > % > The current setting of all hints related to this communicator is returned > in > \mpiarg{info\_used}, including any user-supplied hints that were not > ignored > by the \MPI/ implementation. > % > If no such hints > exist, a handle to a newly created info object is returned that > contains no key/value pair. The user is responsible for freeing > \mpiarg{info\_used} via \mpifunc{MPI\_INFO\_FREE}. > > \begin{users} > The info object returned in \mpiarg{info\_used} will contain all hints > currently active for this communicator. This set of hints may differ > from the set of hints specified during communicator creation or in a call > to \mpifunc{MPI\_COMM\_SET\_INFO}, as some hints and info updates > specified > by the user may be ignored by \MPI/ implementation. Additional info hints > that are set by \MPI/ implementation may also be present. > \end{users} > > Please send feedback! > ~Jim. >

1 0

Get/Set Info Update
by Jim Dinan 23 Jan '17

23 Jan '17

Hi All, I made a first attempt at updating the get/set info text with the feedback from the December meeting. For starters, I'm working with just the communicator get/set info text, so please ignore RMA and I/O for now. For the previous draft of the proposal, please refer to the PDF posted under "references" on the issue page ( https://github.com/mpi-forum/mpi-issues/issues/63) or the existing PR. I pushed the changes to a work-in-progress branch, in case anyone would like to see the history ( https://github.com/mpiwg-p2p/mpi-standard/tree/wip/get-info) You can also compare with the main spec: https://github.com/mpi-forum/mpi-standard/compare/mpi-3.x...mpiwg-p2p:wip/g… Here's the to-do list I captured from the last meeting: 1. Remove info key deletion by omission in calls to set_info (breaks existing semantic) 2. Allow get_info to return keys not set by the user (e.g. "filename" info key) 3. Should get_info return all info keys supported by the implementation? I took a whack at #1 and #2. I'm still thinking about how to handle info keys that don't have good defaults (e.g. "filename") and whether #3 is a good idea. Anyway, without further ado, here is the updated text: MPI_COMM_SET_INFO: \mpifunc{MPI\_COMM\_SET\_INFO} updates the hints of the communicator associated with \mpiarg{comm} using the hints provided in \mpiarg{info}. \mpifunc{MPI\_COMM\_SET\_INFO} is a collective routine. The info object may be different on each process, but any info entries that an implementation requires to be the same on all processes must appear with the same value in each process's info object. \begin{users} Some info items that an implementation can use when it creates a communicator cannot easily be changed once the communicator has been created. Thus, an implementation may ignore hints issued in this call that it would have accepted in a creation call. % An implementation may also be unable to update certain info hints once set. % \mpifunc{MPI\_COMM\_GET\_INFO} can be used to determine whether updates to existing info hints were ignored by the implementation. \end{users} MPI_COMM_GET_INFO: \mpifunc{MPI\_COMM\_GET\_INFO} returns a new info object containing the hints of the communicator associated with \mpiarg{comm}. % The current setting of all hints related to this communicator is returned in \mpiarg{info\_used}, including any user-supplied hints that were not ignored by the \MPI/ implementation. % If no such hints exist, a handle to a newly created info object is returned that contains no key/value pair. The user is responsible for freeing \mpiarg{info\_used} via \mpifunc{MPI\_INFO\_FREE}. \begin{users} The info object returned in \mpiarg{info\_used} will contain all hints currently active for this communicator. This set of hints may differ from the set of hints specified during communicator creation or in a call to \mpifunc{MPI\_COMM\_SET\_INFO}, as some hints and info updates specified by the user may be ignored by \MPI/ implementation. Additional info hints that are set by \MPI/ implementation may also be present. \end{users} Please send feedback! ~Jim.

1 0

Re: [mpiwg-p2p] Meeting today?
by Jim Dinan 19 Dec '16

19 Dec '16

Sounds like the meeting is off for today. I have an update to the info query on my to-do list. I hope to get that out shortly, while the great feedback from the last meeting is still fresh. ~Jim. On Mon, Dec 19, 2016 at 10:08 AM, Jim Dinan <james.dinan(a)gmail.com> wrote: > <eom> > > ~Jim. >

1 0

Meeting today?
by Jim Dinan 19 Dec '16

19 Dec '16

<eom> ~Jim.

1 0

Next meeting: 7th November 2016 11am Central US
by Dan Holmes 07 Nov '16

07 Nov '16

Hi all, The next point-to-point teleconference will be today, Monday 7th November 2016 at 11am Central US via webex. Connection details are on the p2p wiki: https://github.com/mpiwg-p2p/p2p-issues/wiki Agenda: 1) Deprecation of send cancel (issue #26): at the Sept 2016 meeting, Rolf correctly pointed out multiple additional administrative changes that are needed for this. I have completed these changes. We will need 4 reviewers (Rolf + Jim + 2). 2) Communicator assertions (issue #11): at the Sept 2016 meeting, Pavan et al raised the valid objection that fixing the train-wreck of INFO_GET/SET may have knock-on effects on this and so we should delay the vote on it until we have the full picture. 3) Fixing INFO_GET/SET (issue #63): Lots of discussion, mostly captured in the comments for the issue itself. Needs further discussions and decisions. Slides from Sept 2016 meeting with notes on discussion and way forward: https://docs.google.com/presentation/d/10EPCx2LuJ0BWCeUXIG3pXJjqQs1tlnlO-6T… In addition to our this meeting (7th Nov) we have a meeting on 21st Nov, which is the 2-week deadline for the next face-to-face meeting. The way forward for #63 is not simple, so we should aim for a plenary presentation of the work so far. Cheers, Dan. -- Dan Holmes Applications Consultant in HPC Research EPCC, The University of Edinburgh James Clerk Maxwell Building The Kings Buildings Peter Guthrie Tait Road Edinburgh EH9 3FD T: +44(0)131 651 3465 E: dholmes(a)epcc.ed.ac.uk *Please consider the environment before printing this email.* The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. _______________________________________________ mpiwg-p2p mailing list mpiwg-p2p(a)lists.mpi-forum.org https://lists.mpi-forum.org/mailman/listinfo/mpiwg-p2p

1 0

Re: [mpiwg-p2p] Next meeting: 24th October 2016 11am Central US
by Dan Holmes 24 Oct '16

24 Oct '16

Hi Jeff, Thanks - that seems to be working. Cheers, Dan. > On 24 Oct 2016, at 17:17, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> wrote: > > Sorry for the delay; I got distracted by a shiny thing. Here's a new webex: > > https://cisco.webex.com/ciscosales/j.php?MTID=mf29b11dafb923532ff2bf24b3eb9… > > >> On Oct 24, 2016, at 12:12 PM, Jim Dinan <james.dinan(a)gmail.com> wrote: >> >> I can also create a Lync meeting for today, if we need one. >> >> On Mon, Oct 24, 2016 at 12:10 PM, Dan Holmes <dholmes(a)epcc.ed.ac.uk> wrote: >> Hi Jim, >> >> I think that Jeff S is creating a new WebEx for us - I’m going to give him a few more minutes. >> >> Cheers, >> Dan. >> >>> On 24 Oct 2016, at 17:07, Jim Dinan <james.dinan(a)gmail.com> wrote: >>> >>> I'm having trouble getting the webex to work, but I was able to dial in directly using the number below. >>> >>> ~Jim. >>> >>> Audio connection: >>> >>> +1-866-432-9903 Call-in toll-free number (US/Canada) >>> +1-408-525-6800 Call-in toll number (US/Canada) >>> >>> Access code: 201 343 896 >>> >>> On Fri, Oct 21, 2016 at 9:22 AM, Dan Holmes <dholmes(a)epcc.ed.ac.uk> wrote: >>> Hi all, >>> >>> The next point-to-point teleconference will be on Monday 24th October 2016 at 11am Central US via webex. >>> >>> Connection details are on the p2p wiki: >>> https://github.com/mpiwg-p2p/p2p-issues/wiki >>> >>> Agenda: >>> >>> 1) Deprecation of send cancel (issue #26): at the Sept 2016 meeting, Rolf correctly pointed out multiple additional administrative changes that are needed for this. I have completed these changes and Rolf has checked them. We will need 4 reviewers (Rolf + 3). >>> >>> 2) Communicator assertions (issue #11): at the Sept 2016 meeting, Pavan et al raised the valid objection that fixing the train-wreck of INFO_GET/SET may have knock-on effects on this and so we should delay the vote on it until we have the full picture. >>> >>> 3) Fixing INFO_GET/SET (issue #63): I have created a new issue for this and there has been some discussion in the comments and via email. This looks like it needs major re-design work. >>> >>> Slides from Sept 2016 meeting with notes on discussion and way forward: >>> https://docs.google.com/presentation/d/10EPCx2LuJ0BWCeUXIG3pXJjqQs1tlnlO-6T… >>> >>> In addition to this meeting (24th Oct), we will only have 7th Nov before 21st Nov, which is the 2-week deadline for the next face-to-face meeting. >>> >>> Plan: >>> Withdraw #11 from vote on 23rd Sept. [DONE] >>> Create #new and produce a first draft of the text for the Standard. [DONE] >>> Discuss at the meeting on 10th Oct. [INQUORATE] >>> Adjust text for the Standard and produce a first draft of the slides for presenting at the next face-to-face. >>> Discuss at the meeting on 24th Oct. >>> Find and fix all the references and stuff that's needed for a proper proposal (Rolf-proofing). >>> Discuss at the meeting on 7th Nov. >>> Final adjustments for #63, text, and slides. >>> Announce #11 (1st vote) and #63 (reading) to mpi-forum list by 21st Nov. >>> >>> If we discover during the work on #63 that #11 needs to be adjusted then we can re-start its formal procedure with a reading in December. >>> >>> Cheers, >>> Dan. >>> >>> -- >>> Dan Holmes >>> Applications Consultant in HPC Research >>> EPCC, The University of Edinburgh >>> James Clerk Maxwell Building >>> The Kings Buildings >>> Peter Guthrie Tait Road >>> Edinburgh >>> EH9 3FD >>> T: +44(0)131 651 3465 >>> E: dholmes(a)epcc.ed.ac.uk >>> >>> *Please consider the environment before printing this email.* >>> >>> >>> The University of Edinburgh is a charitable body, registered in >>> Scotland, with registration number SC005336. >>> >>> _______________________________________________ >>> mpiwg-p2p mailing list >>> mpiwg-p2p(a)lists.mpi-forum.org >>> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-p2p >>> >>> _______________________________________________ >>> mpiwg-p2p mailing list >>> mpiwg-p2p(a)lists.mpi-forum.org >>> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-p2p >> >> >> The University of Edinburgh is a charitable body, registered in >> Scotland, with registration number SC005336. >> >> _______________________________________________ >> mpiwg-p2p mailing list >> mpiwg-p2p(a)lists.mpi-forum.org >> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-p2p >> >> _______________________________________________ >> mpiwg-p2p mailing list >> mpiwg-p2p(a)lists.mpi-forum.org >> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-p2p > > > -- > Jeff Squyres > jsquyres(a)cisco.com > For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ > > _______________________________________________ > mpiwg-p2p mailing list > mpiwg-p2p(a)lists.mpi-forum.org > https://lists.mpi-forum.org/mailman/listinfo/mpiwg-p2p -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. _______________________________________________ mpiwg-p2p mailing list mpiwg-p2p(a)lists.mpi-forum.org https://lists.mpi-forum.org/mailman/listinfo/mpiwg-p2p

1 0

Re: [mpiwg-p2p] Next meeting: 24th October 2016 11am Central US
by Jeff Squyres (jsquyres) 24 Oct '16

24 Oct '16

Sorry for the delay; I got distracted by a shiny thing. Here's a new webex: https://cisco.webex.com/ciscosales/j.php?MTID=mf29b11dafb923532ff2bf24b3eb9… > On Oct 24, 2016, at 12:12 PM, Jim Dinan <james.dinan(a)gmail.com> wrote: > > I can also create a Lync meeting for today, if we need one. > > On Mon, Oct 24, 2016 at 12:10 PM, Dan Holmes <dholmes(a)epcc.ed.ac.uk> wrote: > Hi Jim, > > I think that Jeff S is creating a new WebEx for us - I’m going to give him a few more minutes. > > Cheers, > Dan. > >> On 24 Oct 2016, at 17:07, Jim Dinan <james.dinan(a)gmail.com> wrote: >> >> I'm having trouble getting the webex to work, but I was able to dial in directly using the number below. >> >> ~Jim. >> >> Audio connection: >> >> +1-866-432-9903 Call-in toll-free number (US/Canada) >> +1-408-525-6800 Call-in toll number (US/Canada) >> >> Access code: 201 343 896 >> >> On Fri, Oct 21, 2016 at 9:22 AM, Dan Holmes <dholmes(a)epcc.ed.ac.uk> wrote: >> Hi all, >> >> The next point-to-point teleconference will be on Monday 24th October 2016 at 11am Central US via webex. >> >> Connection details are on the p2p wiki: >> https://github.com/mpiwg-p2p/p2p-issues/wiki >> >> Agenda: >> >> 1) Deprecation of send cancel (issue #26): at the Sept 2016 meeting, Rolf correctly pointed out multiple additional administrative changes that are needed for this. I have completed these changes and Rolf has checked them. We will need 4 reviewers (Rolf + 3). >> >> 2) Communicator assertions (issue #11): at the Sept 2016 meeting, Pavan et al raised the valid objection that fixing the train-wreck of INFO_GET/SET may have knock-on effects on this and so we should delay the vote on it until we have the full picture. >> >> 3) Fixing INFO_GET/SET (issue #63): I have created a new issue for this and there has been some discussion in the comments and via email. This looks like it needs major re-design work. >> >> Slides from Sept 2016 meeting with notes on discussion and way forward: >> https://docs.google.com/presentation/d/10EPCx2LuJ0BWCeUXIG3pXJjqQs1tlnlO-6T… >> >> In addition to this meeting (24th Oct), we will only have 7th Nov before 21st Nov, which is the 2-week deadline for the next face-to-face meeting. >> >> Plan: >> Withdraw #11 from vote on 23rd Sept. [DONE] >> Create #new and produce a first draft of the text for the Standard. [DONE] >> Discuss at the meeting on 10th Oct. [INQUORATE] >> Adjust text for the Standard and produce a first draft of the slides for presenting at the next face-to-face. >> Discuss at the meeting on 24th Oct. >> Find and fix all the references and stuff that's needed for a proper proposal (Rolf-proofing). >> Discuss at the meeting on 7th Nov. >> Final adjustments for #63, text, and slides. >> Announce #11 (1st vote) and #63 (reading) to mpi-forum list by 21st Nov. >> >> If we discover during the work on #63 that #11 needs to be adjusted then we can re-start its formal procedure with a reading in December. >> >> Cheers, >> Dan. >> >> -- >> Dan Holmes >> Applications Consultant in HPC Research >> EPCC, The University of Edinburgh >> James Clerk Maxwell Building >> The Kings Buildings >> Peter Guthrie Tait Road >> Edinburgh >> EH9 3FD >> T: +44(0)131 651 3465 >> E: dholmes(a)epcc.ed.ac.uk >> >> *Please consider the environment before printing this email.* >> >> >> The University of Edinburgh is a charitable body, registered in >> Scotland, with registration number SC005336. >> >> _______________________________________________ >> mpiwg-p2p mailing list >> mpiwg-p2p(a)lists.mpi-forum.org >> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-p2p >> >> _______________________________________________ >> mpiwg-p2p mailing list >> mpiwg-p2p(a)lists.mpi-forum.org >> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-p2p > > > The University of Edinburgh is a charitable body, registered in > Scotland, with registration number SC005336. > > _______________________________________________ > mpiwg-p2p mailing list > mpiwg-p2p(a)lists.mpi-forum.org > https://lists.mpi-forum.org/mailman/listinfo/mpiwg-p2p > > _______________________________________________ > mpiwg-p2p mailing list > mpiwg-p2p(a)lists.mpi-forum.org > https://lists.mpi-forum.org/mailman/listinfo/mpiwg-p2p -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ _______________________________________________ mpiwg-p2p mailing list mpiwg-p2p(a)lists.mpi-forum.org https://lists.mpi-forum.org/mailman/listinfo/mpiwg-p2p

1 0