September 2013 - mpiwg-tools - mailman3.cels.anl.gov

Re: [mpiwg-tools] Feedback from the forum
by Kathryn Mohror 12 Sep '13

12 Sep '13

Hi Martin, > We read the various tools tickets today and so far, everything seems to look good. Here is the minor feedback we got: > > Ticket 378: the "OUT" is in the wrong font Fixed. > > For MQD: > > Section 3.2.4: of the MPI process -> of an MPI process > > Also, there were questions on the definition of a "unique image" - at the end people seemed to be OK with it, but would like to see a cleaner definition for the next forward looking version of MQD. In particular, it should cover the case where multiple MPI processes are in one OS process. > > Straw votes: > 377: 12 yes, 0 no, 5 abstain > 378: 13 yes, 0 no, 2 abstain Looks like they will pass then! > > Also, someone commented on the example on page 16 of the tools3.pdf document: > > The loop terminates when it hits a non MPI_SUCCESS return from get_info - this is not quite as intended. The loop should jump over holes in the index space (e.g., caused by unloading). I.e., it should test for SUCCESS or INVALID_INDEX and in both cases continue, abort otherwise. > > Bill suggested to fix this as ticket 0. Okay, I'll fix it as ticket 0. Thanks for the summary! Kathryn > > Martin > > _______________________________________________ > mpiwg-tools mailing list > mpiwg-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools ______________________________________________________________ Kathryn Mohror, kathryn(a)llnl.gov, http://people.llnl.gov/mohror1 CASC @ Lawrence Livermore National Laboratory, Livermore, CA, USA

1 0

Re: [mpiwg-tools] Feedback from the forum
by John DelSignore 12 Sep '13

12 Sep '13

I'll also point out that if there's an MPI implementation where an MPI process is a thread in an OS process, and there can be multiple MPI processes in an OS process, then we have no way to represent that in the current MPIR Process Acquisition spec. Currently, MPIR assumes "MPI process" == "OS process". Cheers, John D. Martin Schulz wrote: > On Sep 12, 2013, at 6:25 PM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> wrote: > >> On Sep 12, 2013, at 5:35 PM, Martin Schulz <schulz6(a)llnl.gov> wrote: >> >>> Also, there were questions on the definition of a "unique image" - at the end people seemed to be OK with it, but would like to see a cleaner definition for the next forward looking version of MQD. In particular, it should cover the case where multiple MPI processes are in one OS process. >> I'm not too concerned about this particular piece of feedback: >> >> 1. It came from Torsten who had never read the proposal before. >> 2. If the document doesn't handle the MPI-processes-as-threads concept, then so be it -- this is a documentation of current practice. We welcome their proposal for v2.0 of the document. > > I agree (in case this didn't come across) - it should be OK for the current version, but will be a point of discussion once/if we work on the next generation of the next document. > > Martin > > >> -- >> Jeff Squyres >> jsquyres(a)cisco.com >> For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ >> >> _______________________________________________ >> mpiwg-tools mailing list >> mpiwg-tools(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools > > _______________________________________________ > mpiwg-tools mailing list > mpiwg-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools >

1 0

Re: [mpiwg-tools] Feedback from the forum
by Martin Schulz 12 Sep '13

12 Sep '13

On Sep 12, 2013, at 6:25 PM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> wrote: > On Sep 12, 2013, at 5:35 PM, Martin Schulz <schulz6(a)llnl.gov> wrote: > >> Also, there were questions on the definition of a "unique image" - at the end people seemed to be OK with it, but would like to see a cleaner definition for the next forward looking version of MQD. In particular, it should cover the case where multiple MPI processes are in one OS process. > > I'm not too concerned about this particular piece of feedback: > > 1. It came from Torsten who had never read the proposal before. > 2. If the document doesn't handle the MPI-processes-as-threads concept, then so be it -- this is a documentation of current practice. We welcome their proposal for v2.0 of the document. I agree (in case this didn't come across) - it should be OK for the current version, but will be a point of discussion once/if we work on the next generation of the next document. Martin > > -- > Jeff Squyres > jsquyres(a)cisco.com > For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ > > _______________________________________________ > mpiwg-tools mailing list > mpiwg-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools

1 0

Re: [mpiwg-tools] Feedback from the forum
by Jeff Squyres (jsquyres) 12 Sep '13

12 Sep '13

On Sep 12, 2013, at 5:35 PM, Martin Schulz <schulz6(a)llnl.gov> wrote: > Also, there were questions on the definition of a "unique image" - at the end people seemed to be OK with it, but would like to see a cleaner definition for the next forward looking version of MQD. In particular, it should cover the case where multiple MPI processes are in one OS process. I'm not too concerned about this particular piece of feedback: 1. It came from Torsten who had never read the proposal before. 2. If the document doesn't handle the MPI-processes-as-threads concept, then so be it -- this is a documentation of current practice. We welcome their proposal for v2.0 of the document. -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

Feedback from the forum
by Martin Schulz 12 Sep '13

12 Sep '13

Hi all, We read the various tools tickets today and so far, everything seems to look good. Here is the minor feedback we got: Ticket 378: the "OUT" is in the wrong font For MQD: Section 3.2.4: of the MPI process -> of an MPI process Also, there were questions on the definition of a "unique image" - at the end people seemed to be OK with it, but would like to see a cleaner definition for the next forward looking version of MQD. In particular, it should cover the case where multiple MPI processes are in one OS process. Straw votes: 377: 12 yes, 0 no, 5 abstain 378: 13 yes, 0 no, 2 abstain Also, someone commented on the example on page 16 of the tools3.pdf document: The loop terminates when it hits a non MPI_SUCCESS return from get_info - this is not quite as intended. The loop should jump over holes in the index space (e.g., caused by unloading). I.e., it should test for SUCCESS or INVALID_INDEX and in both cases continue, abort otherwise. Bill suggested to fix this as ticket 0. Martin

1 0

Re: [mpiwg-tools] "read, write, and reset" of pvar
by Martin Schulz 07 Sep '13

07 Sep '13

Hi Junchao, On Sep 6, 2013, at 3:37 PM, Junchao Zhang <jczhang(a)mcs.anl.gov> wrote: > P581~582 of the Standard says > > "Advice to implementors: Sampling-based tools rely on the ability to call the MPI tool information interface, in particular routines to start, stop, read, write and reset performance variables, from any program context, including asynchronous contexts such as signal handlers. MPI implementations should strive, if possible in their particular environment, to enable these usage scenarios for all or a subset of the routines mentioned above. If implementing only a subset, the read, write, and reset routines are typically the most critical for sampling based tools." > > Does the standard really want to say "read, write, reset" are critical or should it be "start, stop, read, reset"? > The signal-safetly "requirement" was part of quite a debate, since this is hard for some platforms. We therefore wanted to be as specific as possible and only ask for a minimal set of functions. The idea was that a tool can always start/stop a variable outside of a signal handler (start of the tool or start of a code segment) and only needs to read the variable during an interrupt. Sure, having all routines signal-safe would be ideal, but that was not acceptable to the forum. Martin > > -- Junchao Zhang > > _______________________________________________ > mpiwg-tools mailing list > mpiwg-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools

1 0

Re: [mpiwg-tools] Continuos counter / timer
by Martin Schulz 07 Sep '13

07 Sep '13

Hi Junchoa, That one we actually specified, although perhaps not in the best/easiest way. Before the table, the standard has the following statement: The starting value is the value that is assigned to the variable the first time that it is used or whenever it is reset. The starting value for a counter is defined as 0. Therefore, the first time you access it, it should return 0. Also, the value can and should return different values in different sessions (relative to when the counter was read first). The idea that we had is that each session maintains a base value that is subtracted from a continuous counter on each read. Hope this make sense, Martin On Sep 6, 2013, at 3:21 PM, Junchao Zhang <jczhang(a)mcs.anl.gov> wrote: > Hello, > If a pvar is a continuos counter (though I think this case is strange), once a handle for it is allocated, what is its value if we read it immediately? Should it be 1) zero or 2) the current value (state) of this variable? > I guess for continuos pvars, all sessions should read the same value if read at the same time. So I think 2) is more reasonable. But the Standard says "the starting value for variables of this class is 0". > > Any comments? Thanks. > > -- Junchao Zhang > _______________________________________________ > mpiwg-tools mailing list > mpiwg-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools

1 0

"read, write, and reset" of pvar
by Junchao Zhang 06 Sep '13

06 Sep '13

P581~582 of the Standard says "Advice to implementors: Sampling-based tools rely on the ability to call the MPI tool information interface, in particular routines to start, stop, read, write and reset performance variables, from any program context, including asynchronous contexts such as signal handlers. MPI implementations should strive, if possible in their particular environment, to enable these usage scenarios for all or a subset of the routines mentioned above. If implementing only a subset, the read, write, and reset routines are typically the most critical for sampling based tools." Does the standard really want to say "read, write, reset" are critical or should it be "start, stop, read, reset"? -- Junchao Zhang

1 0

Continuos counter / timer
by Junchao Zhang 06 Sep '13

06 Sep '13

Hello, If a pvar is a continuos counter (though I think this case is strange), once a handle for it is allocated, what is its value if we read it immediately? Should it be 1) zero or 2) the current value (state) of this variable? I guess for continuos pvars, all sessions should read the same value if read at the same time. So I think 2) is more reasonable. But the Standard says "the starting value for variables of this class is 0". Any comments? Thanks. -- Junchao Zhang

1 0

Re: [mpiwg-tools] MPI_T_pvar_read() on a never-started pvar
by Kathryn Mohror 04 Sep '13

04 Sep '13

Hi Junchao, As far as I can tell, that is an omission. We should have specified the error code to be returned. We'll have to make an errata entry for this. Thanks for bringing this up, Kathryn On Sep 4, 2013, at 3:46 PM, Junchao Zhang <jczhang(a)mcs.anl.gov> wrote: > Hello, > If we read a never-started pvar by MPI_T_pvar_read(), what is supposed to happen? > Read in garbage data or return an error code? If the later, which error code? I don't find it in the standard. > > Thanks > > --Junchao Zhang > _______________________________________________ > mpiwg-tools mailing list > mpiwg-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools ______________________________________________________________ Kathryn Mohror, kathryn(a)llnl.gov, http://people.llnl.gov/mohror1 CASC @ Lawrence Livermore National Laboratory, Livermore, CA, USA

1 0