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

Re: [mpiwg-sessions] intersection of those attending upcoming forum and those interested in a sessions WG meeting
by Dan Holmes 06 Feb '17

06 Feb '17

Hi all, I am definitely interested in progressing the discussions on MPI Sessions in whatever way(s) available. Cheers, Dan. > On 6 Feb 2017, at 19:56, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> wrote: > > Agreed. I unfortunately have a conflict and will not be at this upcoming Forum meeting in Portland. > > >> On Feb 6, 2017, at 2:04 PM, Pritchard Jr., Howard <howardp(a)lanl.gov> wrote: >> >> Hi Folks, >> >> We’re interested in finding out who is attending the upcoming MPI Forum in Portland >> who might be interested in a Sessions working group meeting. Unfortunately some >> of us who are interested in making progress on Sessions will not be able to attend, >> including Jeff S. >> >> If there are enough folks who’d be interested in holding a working group meeting >> (I’m avoiding session here), Jeff can set up a webex for us. >> >> So Jeff and I and Keita would be interested in knowing who might be interested >> in leading/attending such a working group meeting. >> >> Thanks, >> >> >> -- >> Howard Pritchard >> HPC-DES >> Los Alamos National Laboratory >> >> _______________________________________________ >> mpiwg-sessions mailing list >> mpiwg-sessions(a)lists.mpi-forum.org >> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-sessions > > > -- > Jeff Squyres > jsquyres(a)cisco.com > > _______________________________________________ > mpiwg-sessions mailing list > mpiwg-sessions(a)lists.mpi-forum.org > https://lists.mpi-forum.org/mailman/listinfo/mpiwg-sessions -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

1 0

Re: [mpiwg-sessions] intersection of those attending upcoming forum and those interested in a sessions WG meeting
by Jeff Squyres (jsquyres) 06 Feb '17

06 Feb '17

Agreed. I unfortunately have a conflict and will not be at this upcoming Forum meeting in Portland. > On Feb 6, 2017, at 2:04 PM, Pritchard Jr., Howard <howardp(a)lanl.gov> wrote: > > Hi Folks, > > We’re interested in finding out who is attending the upcoming MPI Forum in Portland > who might be interested in a Sessions working group meeting. Unfortunately some > of us who are interested in making progress on Sessions will not be able to attend, > including Jeff S. > > If there are enough folks who’d be interested in holding a working group meeting > (I’m avoiding session here), Jeff can set up a webex for us. > > So Jeff and I and Keita would be interested in knowing who might be interested > in leading/attending such a working group meeting. > > Thanks, > > > -- > Howard Pritchard > HPC-DES > Los Alamos National Laboratory > > _______________________________________________ > mpiwg-sessions mailing list > mpiwg-sessions(a)lists.mpi-forum.org > https://lists.mpi-forum.org/mailman/listinfo/mpiwg-sessions -- Jeff Squyres jsquyres(a)cisco.com

1 0

intersection of those attending upcoming forum and those interested in a sessions WG meeting
by Pritchard Jr., Howard 06 Feb '17

06 Feb '17

Hi Folks, We’re interested in finding out who is attending the upcoming MPI Forum in Portland who might be interested in a Sessions working group meeting. Unfortunately some of us who are interested in making progress on Sessions will not be able to attend, including Jeff S. If there are enough folks who’d be interested in holding a working group meeting (I’m avoiding session here), Jeff can set up a webex for us. So Jeff and I and Keita would be interested in knowing who might be interested in leading/attending such a working group meeting. Thanks, -- Howard Pritchard HPC-DES Los Alamos National Laboratory

1 0

Re: [mpiwg-sessions] meeting today?
by Jeff Squyres (jsquyres) 06 Feb '17

06 Feb '17

Apparently, I have not set the webex link. Sorry folks! There's been bots infesting our webexes recently, and they get the links from scraping the web archives of public lists like this. So I don't want to send the link across this list. Please email me (even today) if you want to join the webex. Thanks. > On Feb 6, 2017, at 1:03 PM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> wrote: > > Yes -- have we not sent out the link prior to this? > > (I'm a bit gun shy on sending the link across a public list these days -- there has been abuse) > > >> On Feb 6, 2017, at 12:59 PM, Pritchard Jr., Howard <howardp(a)lanl.gov> wrote: >> >> Hi Folks, >> >> Are we meeting today? >> >> If so, is there an up-to-date webex link? >> >> Howard >> >> -- >> Howard Pritchard >> HPC-DES >> Los Alamos National Laboratory >> >> _______________________________________________ >> mpiwg-sessions mailing list >> mpiwg-sessions(a)lists.mpi-forum.org >> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-sessions > > > -- > Jeff Squyres > jsquyres(a)cisco.com > > _______________________________________________ > mpiwg-sessions mailing list > mpiwg-sessions(a)lists.mpi-forum.org > https://lists.mpi-forum.org/mailman/listinfo/mpiwg-sessions -- Jeff Squyres jsquyres(a)cisco.com

1 0

Re: [mpiwg-sessions] meeting today?
by Jeff Squyres (jsquyres) 06 Feb '17

06 Feb '17

Yes -- have we not sent out the link prior to this? (I'm a bit gun shy on sending the link across a public list these days -- there has been abuse) > On Feb 6, 2017, at 12:59 PM, Pritchard Jr., Howard <howardp(a)lanl.gov> wrote: > > Hi Folks, > > Are we meeting today? > > If so, is there an up-to-date webex link? > > Howard > > -- > Howard Pritchard > HPC-DES > Los Alamos National Laboratory > > _______________________________________________ > mpiwg-sessions mailing list > mpiwg-sessions(a)lists.mpi-forum.org > https://lists.mpi-forum.org/mailman/listinfo/mpiwg-sessions -- Jeff Squyres jsquyres(a)cisco.com

1 0

meeting today?
by Pritchard Jr., Howard 06 Feb '17

06 Feb '17

Hi Folks, Are we meeting today? If so, is there an up-to-date webex link? Howard -- Howard Pritchard HPC-DES Los Alamos National Laboratory

1 0

Re: [mpiwg-sessions] MPI sessions and MPI T
by Pritchard Jr., Howard 30 Jan '17

30 Jan '17

HI Tony, Responses interweaved below: -- Howard Pritchard HPC-DES Los Alamos National Laboratory From: <mpiwg-sessions-bounces(a)lists.mpi-forum.org<mailto:[email protected]>> on behalf of Dan Holmes <dholmes(a)epcc.ed.ac.uk<mailto:[email protected]>> Reply-To: MPI Sessions working group <mpiwg-sessions(a)lists.mpi-forum.org<mailto:[email protected]>> Date: Friday, January 27, 2017 at 7:07 AM To: MPI Sessions working group <mpiwg-sessions(a)lists.mpi-forum.org<mailto:[email protected]>> Subject: Re: [mpiwg-sessions] MPI sessions and MPI T Hi Howard, Thanks - that looks like a manageably short list. Here’s my initial thoughts. 1) terminology: I’m torn on this - it wouldn’t be the first naming clash in MPI (e.g. MPI_WAIT vs MPI_WIN_WAIT) but that’s no excuse to add another. The name MPI Sessions has achieved some useful brand awareness, which we shouldn’t give up lightly. 2a) For MPI_T_CVAR_GET_INFO, I’m not seeing the conflict. The parameters are {int,string,int,int,MPI_Datatype,} so there is nowhere to pass MPI_COMM_WORLD *as a communicator, i.e. MPI_COMM*. Of course, MCW is a link-time constant handle, so its value can be used pretty much anywhere with suitable casting. I would not expect int george = (int)MPI_COMM_WORLD; to need the communicator represented by the symbol to exist. You’re correct about MPI_T_CVAR_GET_INFO. I overlooked the table 14.2 in section 14.3.2 that describes values returned in the bind out argument. We’ll need to extend this table to include a session handle type. 2b) For MPI_T_CVAR_HANDLE_ALLOC, I like your option of a “not now” error. Alternatively, see (3b) below. 3a) For MPI_T_PVAR_GET_INFO, I’m not seeing the conflict (as for CVAR in (2a) above). Agreed same as above in my response. 3b) For MPI_T_PVAR_HANDLE_ALLOC, would it be possible to attach the pvar to a skeleton mcw and always return dummy/default values (e.g. all counters would stick at zero) when queried? How much of mcw would need to exist (my assumption - none of it)? If some future action causes MCW to be created properly, i.e. MPI_INIT is called, then the pvar would be attached to it during that creation and start giving non-dummy/default answers. This change could be made irrespective of MPI Sessions. MPI_T_INIT(); MPI_T_PVAR_HANDLE_ALLOC(…MCW…); MPI_INIT(); // MCW already has PVAR attached This sounds like a reasonable approach to me. 4) We should allow the session handle to be passed as the obj_handle so that CVARs and PVARs can be attached to MPI Sessions. Yep, at a minimum we should extend the table 14.2 Cheers, Dan. On 27 Jan 2017, at 00:17, Pritchard Jr., Howard <howardp(a)lanl.gov<mailto:[email protected]>> wrote: Hi Folks, I finally got around to a to-do item for the MPI sessions WG. I’d said I’d look through the MPI_T portion of the tools chapter of the standard and see what consequences the MPI Sessions concept would have on that section. I came up with the following short list: * terminology collision. For performance variables, there is an MPI_T_pvar_session construct. However, it seems to me this is sufficiently distinct from what we’re proposing for sessions that there should not be an issue. * MPI_T_CVAR_GET_INFO and MPI_T_CVAR_HANDLE_ALLOC. These have a handle to a MPI object argument. It is legal to pass MPI COMM WORLD/COMM SELF in as the argument. So we’d need to figure out how to handle these cases in the context of an application that doesn’t explicitly call MPI_INIT or one of the other MPI functions that, according to our proposal, has the side effect of creating MPI_COMM_WORLD/SELF. One option might be to return MPI_ T_ ERR_ CVAR_ SET_ NOT_ NOW error code. * A similar problem exists for MPI_T_PVAR_GET_INFO and MPI_T_PVAR_HANDLE_ALLOC. Curiously, there is no analogous MPI_T_ERR_PVAR_SET_NOT_NOW error code. That’s what I came up with for first order items that would be impacted by Sessions, beyond minor languages changes in the text to indicate, for instance, that a Session handle could be passed to MPI_T_CVAR_HANDLE_ALLOC, etc. Howard -- Howard Pritchard HPC-DES Los Alamos National Laboratory _______________________________________________ mpiwg-sessions mailing list mpiwg-sessions(a)lists.mpi-forum.org<mailto:[email protected]> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-sessions

1 0

Re: [mpiwg-sessions] MPI sessions and MPI T
by Dan Holmes 27 Jan '17

27 Jan '17

Hi Howard, Thanks - that looks like a manageably short list. Here’s my initial thoughts. 1) terminology: I’m torn on this - it wouldn’t be the first naming clash in MPI (e.g. MPI_WAIT vs MPI_WIN_WAIT) but that’s no excuse to add another. The name MPI Sessions has achieved some useful brand awareness, which we shouldn’t give up lightly. 2a) For MPI_T_CVAR_GET_INFO, I’m not seeing the conflict. The parameters are {int,string,int,int,MPI_Datatype,} so there is nowhere to pass MPI_COMM_WORLD *as a communicator, i.e. MPI_COMM*. Of course, MCW is a link-time constant handle, so its value can be used pretty much anywhere with suitable casting. I would not expect int george = (int)MPI_COMM_WORLD; to need the communicator represented by the symbol to exist. 2b) For MPI_T_CVAR_HANDLE_ALLOC, I like your option of a “not now” error. Alternatively, see (3b) below. 3a) For MPI_T_PVAR_GET_INFO, I’m not seeing the conflict (as for CVAR in (2a) above). 3b) For MPI_T_PVAR_HANDLE_ALLOC, would it be possible to attach the pvar to a skeleton mcw and always return dummy/default values (e.g. all counters would stick at zero) when queried? How much of mcw would need to exist (my assumption - none of it)? If some future action causes MCW to be created properly, i.e. MPI_INIT is called, then the pvar would be attached to it during that creation and start giving non-dummy/default answers. This change could be made irrespective of MPI Sessions. MPI_T_INIT(); MPI_T_PVAR_HANDLE_ALLOC(…MCW…); MPI_INIT(); // MCW already has PVAR attached 4) We should allow the session handle to be passed as the obj_handle so that CVARs and PVARs can be attached to MPI Sessions. Cheers, Dan. > On 27 Jan 2017, at 00:17, Pritchard Jr., Howard <howardp(a)lanl.gov <mailto:[email protected]>> wrote: > > Hi Folks, > > I finally got around to a to-do item for the MPI sessions WG. I’d said > I’d look through the MPI_T portion of the tools chapter of the standard > and see what consequences the MPI Sessions concept would have on that > section. > > I came up with the following short list: > terminology collision. For performance variables, there is an MPI_T_pvar_session construct. However, it seems to me this is sufficiently distinct from what we’re proposing for sessions that there should not be an issue. > MPI_T_CVAR_GET_INFO and MPI_T_CVAR_HANDLE_ALLOC. These have a handle to a MPI object argument. It is legal to pass MPI COMM WORLD/COMM SELF in as the argument. So we’d need to figure out how to handle these cases in the context of an application that doesn’t explicitly call MPI_INIT or one of the other MPI functions that, according to our proposal, has the side effect of creating MPI_COMM_WORLD/SELF. One option might be to return MPI_ T_ ERR_ CVAR_ SET_ NOT_ NOW error code. > A similar problem exists for MPI_T_PVAR_GET_INFO and MPI_T_PVAR_HANDLE_ALLOC. Curiously, there is no analogous MPI_T_ERR_PVAR_SET_NOT_NOW error code. > That’s what I came up with for first order items that would be impacted by Sessions, beyond minor languages changes in the text to indicate, for instance, that a Session handle could be passed to MPI_T_CVAR_HANDLE_ALLOC, etc. > > Howard > > > -- > Howard Pritchard > HPC-DES > Los Alamos National Laboratory > > _______________________________________________ > mpiwg-sessions mailing list > mpiwg-sessions(a)lists.mpi-forum.org <mailto:[email protected]> > https://lists.mpi-forum.org/mailman/listinfo/mpiwg-sessions The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

1 0

MPI sessions and MPI T
by Pritchard Jr., Howard 26 Jan '17

26 Jan '17

Hi Folks, I finally got around to a to-do item for the MPI sessions WG. I’d said I’d look through the MPI_T portion of the tools chapter of the standard and see what consequences the MPI Sessions concept would have on that section. I came up with the following short list: * terminology collision. For performance variables, there is an MPI_T_pvar_session construct. However, it seems to me this is sufficiently distinct from what we’re proposing for sessions that there should not be an issue. * MPI_T_CVAR_GET_INFO and MPI_T_CVAR_HANDLE_ALLOC. These have a handle to a MPI object argument. It is legal to pass MPI COMM WORLD/COMM SELF in as the argument. So we’d need to figure out how to handle these cases in the context of an application that doesn’t explicitly call MPI_INIT or one of the other MPI functions that, according to our proposal, has the side effect of creating MPI_COMM_WORLD/SELF. One option might be to return MPI_ T_ ERR_ CVAR_ SET_ NOT_ NOW error code. * A similar problem exists for MPI_T_PVAR_GET_INFO and MPI_T_PVAR_HANDLE_ALLOC. Curiously, there is no analogous MPI_T_ERR_PVAR_SET_NOT_NOW error code. That’s what I came up with for first order items that would be impacted by Sessions, beyond minor languages changes in the text to indicate, for instance, that a Session handle could be passed to MPI_T_CVAR_HANDLE_ALLOC, etc. Howard -- Howard Pritchard HPC-DES Los Alamos National Laboratory

1 0

Meeting canceled today
by Jeff Squyres (jsquyres) 23 Jan '17

23 Jan '17

Sorry folks; I'm traveling today and can't make the call. I realize this is 2 meetings in a row I've canceled; sorry about that! -- Jeff Squyres jsquyres(a)cisco.com

1 0