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

Re: [Mpi3-tools] draft MPIT hierarchy query function text
by William Gropp 05 Mar '10

05 Mar '10

I'm in favor of this approach - the text based interface is most useful to end users, not to the tool middleware that is most likely to need this functionality. Bill On Mar 5, 2010, at 11:07 AM, Dave Goodell wrote: > Feedback on this proposal would be appreciated. Should I proceed or > will I be wasting my time? > > -Dave > > On Mar 2, 2010, at 6:09 PM, Dave Goodell wrote: > >> Enclosed is alternative text for the MPIT draft. This text replaces >> the "Set and Hierarchy Information" \subsubsection in 1.3.5 in the >> current draft PDF (md5sum: 4fa7d0f3a25cabce8c2f5ef95bb41599). My >> motivation for this alternative interface is to avoid pushing the >> burden of text parsing onto all tools that which to utilize >> hierarchy information. As I mentioned at the last concall, I >> believe that few or no tools will want to work with the text format >> directly and will instead always access this information through a >> functional interface. >> >> The text below has many "...MORE TEXT HERE..." points indicating >> where the text should be expanded in a fashion consistent with the >> rest of the MPIT text. I'm happy to finish writing this text but I >> wanted to get the rough shape of the proposal out for comment before >> I take the time to fill in the non-essential details. If I've >> omitted too much in a particular area, please ask and I'll clarify >> what I had in mind. >> >> Discussion items: >> >> * function names: did we decide that iterative functions should be >> named _ITER or similar? >> * function names: most of these are listed as starting with >> MPIT_TAXA (as in taxonomy) in order to avoid verb/noun confusion >> with the word "SET". I am open to alternative names, such as >> MPIT_TAXONOMY, MPIT_HIERARCHY, MPIT_CLASSIFICATION, MPIT_GROUP. >> (the first three are long, the last has potential for confusion with >> MPI_Group) Maybe MPIT_VARGROUP? >> * iteration order: does the topological order requirement help >> client code or is it just additional burden for MPI implementors? >> * I've eliminated the "pretty names" for sets. I'm assuming that >> the uniquely identifying name is sufficient and that anything that >> needs to be spelled out more explicitly for humans should go into >> the description information. If anyone disagrees with this, I can >> add the pretty names back in. >> * I think it also makes sense to move the rewritten \subsubsection >> to after the "Query and Handle Functions" \subsubsection. It is >> easier to talk about grouping performance variables once the reader >> knows a bit more about what performance variables actually are. >> >> -Dave >> >> ------8<------ >> Performance Variable Taxonomic Information >> >> MPI implementations can optionally provide information that >> describes the relationship of performance variables to each other. >> For this, an MPI implementation can define names that represent sets >> of variables and then associate each performance variable with zero >> or more sets. Sets may contain zero or more performance variables >> and zero or more other sets. Sets may not contain themselves either >> directly or indirectly. Said another way, these sets and >> performance variables form a directed acyclic graph (DAG). This >> information is accessible via several interrogative routines. >> >> MPIT_TAXA_QUERY_ALL_SETS(iterator, name, namelen) >> >> INOUT iterator >> OUT name >> OUT namelen >> >> Iterate over all sets in topological order. A unique identifying >> name for the set is returned in "name" and "namelen" is set to the >> number of characters written. The value of "namelen" cannot be >> larger than MPIT_MAX_SET_NAME-1. >> ...MORE TEXT HERE... >> >> MPIT_TAXA_QUERY_VARIABLE_SETS(iterator, varname, name, namelen) >> >> INOUT iterator >> IN varname >> OUT name >> OUT namelen >> >> Iterate over all sets that contain the performance variable >> identified by "varname". >> ...MORE TEXT HERE... >> >> MPIT_TAXA_QUERY_SET_SETS(iterator, setname, name, namelen) >> >> INOUT iterator >> IN setname >> OUT name >> OUT namelen >> >> Iterate over all sets that contained in the set identified by >> "setname". >> ...MORE TEXT HERE... >> >> MPIT_TAXA_QUERY_SET_VARIABLES(iterator, setname, name, namelen) >> >> Iterate over all variables contained in the set identified by >> "setname". >> ...MORE TEXT HERE... >> >> MPIT_TAXA_SET_DESCRIBE(name, desc, desclen) >> >> IN name >> OUT desc >> OUT desclen >> >> Retrieve the description for the set identified by "name". >> ...MORE TEXT HERE... >> ------8<------ >> >> Also, delete the "sets" and "setslen" parameters to >> MPIT_PERFORMANCE_INFO. Delete the paragraphs contained in lines >> 7-16 of page 19 ("The argument sets ... setslen must be set to >> zero."). >> >> _______________________________________________ >> Mpi3-tools mailing list >> Mpi3-tools(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools > > _______________________________________________ > Mpi3-tools mailing list > Mpi3-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools William Gropp Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign

1 0

Re: [Mpi3-tools] draft MPIT hierarchy query function text
by Dave Goodell 05 Mar '10

05 Mar '10

Feedback on this proposal would be appreciated. Should I proceed or will I be wasting my time? -Dave On Mar 2, 2010, at 6:09 PM, Dave Goodell wrote: > Enclosed is alternative text for the MPIT draft. This text replaces > the "Set and Hierarchy Information" \subsubsection in 1.3.5 in the > current draft PDF (md5sum: 4fa7d0f3a25cabce8c2f5ef95bb41599). My > motivation for this alternative interface is to avoid pushing the > burden of text parsing onto all tools that which to utilize > hierarchy information. As I mentioned at the last concall, I > believe that few or no tools will want to work with the text format > directly and will instead always access this information through a > functional interface. > > The text below has many "...MORE TEXT HERE..." points indicating > where the text should be expanded in a fashion consistent with the > rest of the MPIT text. I'm happy to finish writing this text but I > wanted to get the rough shape of the proposal out for comment before > I take the time to fill in the non-essential details. If I've > omitted too much in a particular area, please ask and I'll clarify > what I had in mind. > > Discussion items: > > * function names: did we decide that iterative functions should be > named _ITER or similar? > * function names: most of these are listed as starting with > MPIT_TAXA (as in taxonomy) in order to avoid verb/noun confusion > with the word "SET". I am open to alternative names, such as > MPIT_TAXONOMY, MPIT_HIERARCHY, MPIT_CLASSIFICATION, MPIT_GROUP. > (the first three are long, the last has potential for confusion with > MPI_Group) Maybe MPIT_VARGROUP? > * iteration order: does the topological order requirement help > client code or is it just additional burden for MPI implementors? > * I've eliminated the "pretty names" for sets. I'm assuming that > the uniquely identifying name is sufficient and that anything that > needs to be spelled out more explicitly for humans should go into > the description information. If anyone disagrees with this, I can > add the pretty names back in. > * I think it also makes sense to move the rewritten \subsubsection > to after the "Query and Handle Functions" \subsubsection. It is > easier to talk about grouping performance variables once the reader > knows a bit more about what performance variables actually are. > > -Dave > > ------8<------ > Performance Variable Taxonomic Information > > MPI implementations can optionally provide information that > describes the relationship of performance variables to each other. > For this, an MPI implementation can define names that represent sets > of variables and then associate each performance variable with zero > or more sets. Sets may contain zero or more performance variables > and zero or more other sets. Sets may not contain themselves either > directly or indirectly. Said another way, these sets and > performance variables form a directed acyclic graph (DAG). This > information is accessible via several interrogative routines. > > MPIT_TAXA_QUERY_ALL_SETS(iterator, name, namelen) > > INOUT iterator > OUT name > OUT namelen > > Iterate over all sets in topological order. A unique identifying > name for the set is returned in "name" and "namelen" is set to the > number of characters written. The value of "namelen" cannot be > larger than MPIT_MAX_SET_NAME-1. > ...MORE TEXT HERE... > > MPIT_TAXA_QUERY_VARIABLE_SETS(iterator, varname, name, namelen) > > INOUT iterator > IN varname > OUT name > OUT namelen > > Iterate over all sets that contain the performance variable > identified by "varname". > ...MORE TEXT HERE... > > MPIT_TAXA_QUERY_SET_SETS(iterator, setname, name, namelen) > > INOUT iterator > IN setname > OUT name > OUT namelen > > Iterate over all sets that contained in the set identified by > "setname". > ...MORE TEXT HERE... > > MPIT_TAXA_QUERY_SET_VARIABLES(iterator, setname, name, namelen) > > Iterate over all variables contained in the set identified by > "setname". > ...MORE TEXT HERE... > > MPIT_TAXA_SET_DESCRIBE(name, desc, desclen) > > IN name > OUT desc > OUT desclen > > Retrieve the description for the set identified by "name". > ...MORE TEXT HERE... > ------8<------ > > Also, delete the "sets" and "setslen" parameters to > MPIT_PERFORMANCE_INFO. Delete the paragraphs contained in lines > 7-16 of page 19 ("The argument sets ... setslen must be set to > zero."). > > _______________________________________________ > Mpi3-tools mailing list > Mpi3-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools

1 0

Re: [Mpi3-tools] DRAFT of the MPIR Process Acquisition Interface document
by William Gropp 03 Mar '10

03 Mar '10

Thanks, John. I've read through it quickly and I have a few comments. Page 3: What are the units of the value in MPIR_proctablesize? (bytes, elements, ints, ...) Page 3: An MPIR_Event is introduced. Is this the definition of an MPIR_Event? It might be best to have a separate definition first. Page 4ff: MPICH 1 should probably be written as MPICH-1 or MPICH1 or just MPICH (the MPICH<space>1 is awkward). Page 5ff: mpirun vs mpiexec . Its true that mpirun is the most common name, but mpiexec has been the preferred and *official, standard sanctioned* name for over 12 (!) years. I'd like the document to recognize that mpiexec is the correct name for the program that may be used to start MPI programs, and mention that mpirun is non- standard, but historical and still widely used, name. Page 8, Table 1: Thank you! (I haven't gone through it in detail, but this is a great thing to have) Page 11, first line: "is specified a set" should be either "specified a set" or "is specified as a set". Page 11, definition of VOLATILE. I'm concerned about this. First, it requires that VOLATILE be defined as empty if __STDC__ and __cplusplus are not defined - shouldn't volatile be allowed if supported? More seriously, if volatile is not supported, can the interface work? If so, then why include VOLATILE? Page 11, MPIR_PROCDESC description. Is the pid an int (unknown size) or an int of a specific size? The text suggests that it is an int of an unspecified size (the tool must determine). May be worth a reminder to implementors, particularly on systems where ints may be different sizes depending on compilation options. Page 12ff: const, volatile, and the declarations. I think we should look over the declarations carefully to see whether they should include const and/or volatile . For example, MPIR_debug_state is declared without volatile - shouldn't volatile be used for any variable that (a) may be changed and (b) read by another agent (such as the debug tool)? There's also one array declaration that uses "char MPIR_dll_name[];"; the others all use pointers ("char *MPIR_debug_abort_string") (not counting the ones that allocate storage, e.g., char MPIR_executable_path[256]), which itself seems dangerously small. All in all, an excellent and valuable start. Thanks, John! Bill On Feb 27, 2010, at 11:39 AM, John DelSignore wrote: > Hi all, > > Attached is DRAFT copy of a document in PDF format that contains a > description of the MPIR Process Acquisition Interface. I think it's > still pretty raw and there's more information and clarification > needed, but it is fairly complete and should serve as solid > foundation material for a more formal interface description that > could be incorporated into the standard. I can be prepared to > discuss this paper during the March 2010 meeting, if the MPI-3 Tools > Workgroup deems it appropriate. > > Note that to date, I have made no effort to more formally document > the MPIR Message Queue Display Interface. I inserted a placeholder > at the end of the attached document as a reminder that this is a TO- > DO item. > > Cheers, John D. > <MPIR Process Acquisition Interface.pdf><ATT00001..txt> William Gropp Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign

1 0

[Mpi3-tools] draft MPIT hierarchy query function text
by Dave Goodell 02 Mar '10

02 Mar '10

Enclosed is alternative text for the MPIT draft. This text replaces the "Set and Hierarchy Information" \subsubsection in 1.3.5 in the current draft PDF (md5sum: 4fa7d0f3a25cabce8c2f5ef95bb41599). My motivation for this alternative interface is to avoid pushing the burden of text parsing onto all tools that which to utilize hierarchy information. As I mentioned at the last concall, I believe that few or no tools will want to work with the text format directly and will instead always access this information through a functional interface. The text below has many "...MORE TEXT HERE..." points indicating where the text should be expanded in a fashion consistent with the rest of the MPIT text. I'm happy to finish writing this text but I wanted to get the rough shape of the proposal out for comment before I take the time to fill in the non-essential details. If I've omitted too much in a particular area, please ask and I'll clarify what I had in mind. Discussion items: * function names: did we decide that iterative functions should be named _ITER or similar? * function names: most of these are listed as starting with MPIT_TAXA (as in taxonomy) in order to avoid verb/noun confusion with the word "SET". I am open to alternative names, such as MPIT_TAXONOMY, MPIT_HIERARCHY, MPIT_CLASSIFICATION, MPIT_GROUP. (the first three are long, the last has potential for confusion with MPI_Group) Maybe MPIT_VARGROUP? * iteration order: does the topological order requirement help client code or is it just additional burden for MPI implementors? * I've eliminated the "pretty names" for sets. I'm assuming that the uniquely identifying name is sufficient and that anything that needs to be spelled out more explicitly for humans should go into the description information. If anyone disagrees with this, I can add the pretty names back in. * I think it also makes sense to move the rewritten \subsubsection to after the "Query and Handle Functions" \subsubsection. It is easier to talk about grouping performance variables once the reader knows a bit more about what performance variables actually are. -Dave ------8<------ Performance Variable Taxonomic Information MPI implementations can optionally provide information that describes the relationship of performance variables to each other. For this, an MPI implementation can define names that represent sets of variables and then associate each performance variable with zero or more sets. Sets may contain zero or more performance variables and zero or more other sets. Sets may not contain themselves either directly or indirectly. Said another way, these sets and performance variables form a directed acyclic graph (DAG). This information is accessible via several interrogative routines. MPIT_TAXA_QUERY_ALL_SETS(iterator, name, namelen) INOUT iterator OUT name OUT namelen Iterate over all sets in topological order. A unique identifying name for the set is returned in "name" and "namelen" is set to the number of characters written. The value of "namelen" cannot be larger than MPIT_MAX_SET_NAME-1. ...MORE TEXT HERE... MPIT_TAXA_QUERY_VARIABLE_SETS(iterator, varname, name, namelen) INOUT iterator IN varname OUT name OUT namelen Iterate over all sets that contain the performance variable identified by "varname". ...MORE TEXT HERE... MPIT_TAXA_QUERY_SET_SETS(iterator, setname, name, namelen) INOUT iterator IN setname OUT name OUT namelen Iterate over all sets that contained in the set identified by "setname". ...MORE TEXT HERE... MPIT_TAXA_QUERY_SET_VARIABLES(iterator, setname, name, namelen) Iterate over all variables contained in the set identified by "setname". ...MORE TEXT HERE... MPIT_TAXA_SET_DESCRIBE(name, desc, desclen) IN name OUT desc OUT desclen Retrieve the description for the set identified by "name". ...MORE TEXT HERE... ------8<------ Also, delete the "sets" and "setslen" parameters to MPIT_PERFORMANCE_INFO. Delete the paragraphs contained in lines 7-16 of page 19 ("The argument sets ... setslen must be set to zero.").

1 0

[Mpi3-tools] DRAFT of the MPIR Process Acquisition Interface document
by John DelSignore 27 Feb '10

27 Feb '10

Hi all, Attached is DRAFT copy of a document in PDF format that contains a description of the MPIR Process Acquisition Interface. I think it's still pretty raw and there's more information and clarification needed, but it is fairly complete and should serve as solid foundation material for a more formal interface description that could be incorporated into the standard. I can be prepared to discuss this paper during the March 2010 meeting, if the MPI-3 Tools Workgroup deems it appropriate. Note that to date, I have made no effort to more formally document the MPIR Message Queue Display Interface. I inserted a placeholder at the end of the attached document as a reminder that this is a TO-DO item. Cheers, John D.

1 0

Re: [Mpi3-tools] Comments on 2/22 draft
by Marc-Andre Hermanns 23 Feb '10

23 Feb '10

Hi Jeff, > - 1.3.5: what's the difference between a VARCLASS_UTILIZATION and a > VARCLASS_RESOURCE? They both say they're measuring resources in the > MPI library. One is "absolute", but I don't know what that means. VARCLASS_UTILIZATION is the ratio of VARCLASS_RESOURCE and whatever the maximum of that variable is. Example: Consider a queue for incoming messages with place for 10 messages. With 2 messages currently being in the queue, you would get VARCLASS_UTILIZATION=0.2 VARCLASS_RESOURCE=2 That's how I understand the text, however, I also recommend rephrasing the text to make it clearer. > - Why do we need a profiling interface for MPIT? It's already a tool > interface. You could profile your tools, and the MPIT interface. Also, when we open this to 'the user', which takes the same line as having a Fortran interface for this, you want time spent here accounted to time spent in MPI and not in user-code, right? Best regards, Marc-Andre -- Marc-Andre Hermanns Juelich Supercomputing Centre Institute for Advanced Simulation Forschungszentrum Juelich GmbH D-52425 Juelich Germany Phone : +49-2461-61-2054 Fax : +49-2461-61-6656 eMail : m.a.hermanns(a)fz-juelich.de WWW : http://www.fz-juelich.de/jsc/ JSC is the coordinator of the John von Neumann Institute for Computing and member of the Gauss Centre for Supercomputing Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzende des Aufsichtsrats: MinDir'in Baerbel Brumme-Bothe Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr. Harald Bolt, Prof. Dr. Sebastian M. Schmidt

1 0

[Mpi3-tools] Comments on 2/22 draft
by Jeff Squyres 22 Feb '10

22 Feb '10

Here's my comments on the rest of the draft: - 1.3.5: what's the difference between a VARCLASS_UTILIZATION and a VARCLASS_RESOURCE? They both say they're measuring resources in the MPI library. One is "absolute", but I don't know what that means. - High/low watermarks: they're both unsigned and monotonically growing or shrinking. What happens on rollover? - What's the units of VARCLASS_TIMER? - The set and hierarchy information grammar description appears to be a pseudo-regexp kind of notation that is not explained. I can guess what it means, but I think that the grammar should be explicitly defined with no assumptions. - Example 1.1: seems to flow into 2 xamples. Should the second one be Example 1.2? - p16 line 9 says "Additionally, a second performance variable..." Is that on a second performance variable, or a 2nd collection on the same variable? The phrase is ambiguous. - What are tools expected to do with the collection string info (other than print them out)? - MPIT_GET_SETINFO is just a weird function name -- it has both "GET" and "SET" in the name (I know it's the *other* "set", but it's still weird). - Some functions have GET/SET, some have QUERY, some have READ/WRITE. Some functions have the verb 2nd, some have it 3rd. Can we be consistent? It might be useful to list out all MPIT_ functions in a list and compare them for consistency (why don't they show up in the function index, btw?). - Sidenote: why does MPI_INIT show up twice in the function index? Why does mpiexec and "PMPI_" show up in the function index? - p16 line 31 says that you have to return MPIT_ERR_NODATA if you don't return the description. What if some error occurred (e.g., the set wasn't found). Do you still have to return MPIT_ERR_NODATA? The way it's currently worded, it sounds like you still have to return MPI_ERR_NODATA for any error that results in the description not being returned. - Random question: several places throughout the doc, we refer to ASCII. Should we be using UTF-8 instead? - Language nit: in several places throughout the doc, there's language like the first character for desc must be set to the null character and desclen must be set to zero. Shouldn't it really be phrased something more like s/must/will/g? I.e., the first character for desc will be set to the null character and desclen will be set to zero. I ask because we're describing the behavior that will occur, not necessarily describing rules that must be folloed for an implementation. In the above sentence, the distinction probably doesn't matter much because the two are pretty much the same thing. But in other places, it may matter -- we don't specify the implementation, we only say what the end state will be. - For the MPI_PERFORMANCE_* functions, can we point to the MPI_CONFIG_* functions, and say something like "the functionality is the same as MPI_CONFIG_<foo>, with the following exceptions..." (rather than replicating all the text)? If there's lots of little differences, this may not be worth it, but I thought I'd ask. - MPIT_PERFORMANCE_INFO: p18 line 35, should be a "null terminated string", not a "zero terminated string". I didn't check to see if this phraseology appears elsewhere. - p19 line 18 says "...the variable is only initialized at MPIT_INIT" Which call to MPIT_INIT are you referring to (if it can be called many times)? - There's a bunch of places in the doc that refers to the user. There is no user here, right? There's only the application that is invoking this API. Whether or not there is a user that is choosing to make specific API calls is an entirely different issue. - MPIT_Performancehandle is a redundant name, IMHO. All MPIT_<foo> types are handles, no? If we're going for 2 word names, I'd advocate for an underscore between them (e.g., MPIT_<foo>_<bar>, not MPIT_<foo><bar>). - MPIT_Performance_gethandle != the opposite of MPIT_Performance_freehandle. I.e., get is not the opposite of free. Use create/free instead? - p20 line 18: "However, it is possible to recreate a handle for the same variable at a later time." This sentence says to me that it must be possible to exactly recreate the same handle. I think you meant to say that you can get another handle for the same variable later. It may or may not be exaclty the same as a prior handle to that variable, but I don't think we want to mandate it. - p 18 line 24: "Performance variables that have the continuous flag set during the query operation" s/during/by/ - Same line, "Performance variables that have the continuous flag set during the query operation are continuously operating after a call to MPIT_Init and can not be stopped or paused by the user." Variables are not stopped, paused, or running. You can have a value that is continually changing, but the definition of a variable is a value. The behavior of the value of a variable is something that can change; but a variable itself is not something that is "run" or "stopped" or "paused". - MPIT_PERFORMANCE_WRITE returning an error code that is essentially the same as the function name seems pretty weird -- it could mean anything. If you're not allowed to write to the variable, how about returning MPI_ERR_PERF_READONLY? - Ditto for MPIT_PERFORMANCE_RESET and _READRESET. - ATI on p22 -- can you refer to the prior ATI that had just about exactly the same wording rather than duplicating the text? - MPIT_ERR_* tables: will there be any other error values? Like MPIT_ERR_INVAL, or MPIT_ERR_NOMEM? Or ...? - Why do we need a profiling interface for MPIT? It's already a tool interface. Hope this helps! -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

[Mpi3-tools] Feedback on current draft
by Marc-Andre Hermanns 22 Feb '10

22 Feb '10

Hi all, in preparation of our call today, I read the current draft. Here are some comments: page 9, line 24: ---------------- I would rephrase: "This routine returns, if datatype represents a valid enumeration type, the size of the enumeration as well as a name for it." to "If datatype represents a valid enumeration type, this routine returns the size of the enumeration as well as a name for it." page 11, line 6: ---------------- Isn't UNIX a trademarked name? Do we have to acknowledge that on some other page in any way? page 11, line 36: ----------------- ... set ... -> ... sets ... page 13, Table 1.4: ------------------- might it be interesting to have a scope like "MPIT_SCOPE_AFTER_COMM_COMPLETION" (I admit the name is terrible), to indicate that this variable can be changed when no messages are "in flight"? Is there need for such a state? Would the 'eager limit' for example be ANYTIME? page 13, config vars in general: -------------------------------- Is there a reason why we don't have a 'gethandle' for the config vars? Wouldn't/Couldn't it be interesting to quickly check a variable value like 'eager limit' against the bytes sent in a sent, right in the wrapper. Wouldn't the handle call then have less overhead than the string-key call? page 14, line 25: ----------------- Is there a reason why the UTILIZATION paragraph is the only paragraph starting with a different style? I would also mention that utilization means the "ratio" between used resource to totally available resource. This would also make the value between 0 and 1 quite clear. That's all for now, I think. Best regards, Marc-Andre -- Marc-Andre Hermanns Juelich Supercomputing Centre Institute for Advanced Simulation Forschungszentrum Juelich GmbH D-52425 Juelich Germany Phone : +49-2461-61-2054 Fax : +49-2461-61-6656 eMail : m.a.hermanns(a)fz-juelich.de WWW : http://www.fz-juelich.de/jsc/ JSC is the coordinator of the John von Neumann Institute for Computing and member of the Gauss Centre for Supercomputing Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzende des Aufsichtsrats: MinDir'in Baerbel Brumme-Bothe Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr. Harald Bolt, Prof. Dr. Sebastian M. Schmidt

1 0

Re: [Mpi3-tools] alternative signal handler text
by William Gropp 21 Feb '10

21 Feb '10

For a standard, the issue is whether *all* implementations are Unix- like, and for MPI, there are definitely some that aren't Unix-like, and there are likely to be more (I don't want to see Unix running on each of the 10,000,000 nodes of my Exascale system). Handling this is what the advice to implementor is for - the Forum can remind implementors about things that may apply to some but not all implementations. We've also taken the position that many of these issues should be "quality of implementation" rather than mandating specific behavior. In this case, an advice to implementors should be all that is necessary to ensure that an implementation doesn't do something weird by mistake. Bill On Feb 21, 2010, at 8:57 AM, Marty Itzkowitz wrote: > Aren't most implementations of MPI Unix or Unix-like? Why can't > this fact > be used in writing a definition? William Gropp Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign

1 0

Re: [Mpi3-tools] alternative signal handler text
by Marty Itzkowitz 21 Feb '10

21 Feb '10

On 2/21/10 12:55 AM, Martin Schulz wrote: > Hi Bill and Dave, > > This is certainly not ideal from a tool's perspective, since there is > nothing it > can rely on. However, I understand the restrictions of the language in > the > MPI standard and we need to make this acceptable across the whole > forum. I made the change in the document. > > The question is, though, can we add a mechanism for a tool to find out > whether it is safe to call the routine from a particular context? To > avoid > the same problem in the description of this such a query mechanism, > we could add a routine that returns whether a call is possible in the > current context (independent of what it is). Would this work and be > helpful? Not really. It's no different from returning an error code in that context. Aren't most implementations of MPI Unix or Unix-like? Why can't this fact be used in writing a definition? Marty > > Martin > > > On Feb 17, 2010, at 7:24 AM, William Gropp wrote: > >> I second Dave's note. A "signal handler" is a concept that depends >> on the OS; Dave's text is more appropriate for an OS-agnostic >> standard. Dave's text is also more in the spirit of the MPI >> standard, which allows implementations to make performance tradeoffs >> while reminding implementors what the Forum feels most users will >> expect. >> >> Bill >> >> On Feb 16, 2010, at 5:15 PM, Dave Goodell wrote: >> >>> (comments are relative to the draft PDF retrieved 2010-02-16 @ 4:30pm >>> CST with md5sum "0fd54c6370574a93db13d3f5589d4b98") >>> >>> I would like to propose alternative text for signal handling in the >>> MPIT performance interface. The relevant text from the current draft >>> (page 21, lines 3-5 and page 22, lines 24-25) is reproduced below: >>> >>> -------8<------- >>> 3| The routines in this section to start and stop performance >>> variables must be safely >>> 4| callable from any asynchronous execution context, such as a >>> signal or interrupt handler, to >>> 5| allow their use in sampling-based tools. >>> ... >>> 24| The routines in this section to read, write, and reset >>> performance variables must be >>> 25| callable from signal handlers to allow their use in sampling- >>> based tools. >>> -------8<------- >>> >>> My proposed alternative: >>> -------8<------- >>> Advice to implementors. Although MPI places no requirements on the >>> interaction with external mechanisms such as signal handlers, it is >>> strongly recommended that the routines in this section to start and >>> stop performance variables should be safe to call in asynchronous >>> contexts. Examples of asynchronous contexts include signal handlers >>> and interrupt handlers. Such safety permits the development of >>> sampling-based tools. High quality implementations should strive to >>> make the results of any such interactions intuitive to users, and >>> attempt to document restrictions where deemed necessary. (End of >>> advice to implementors.) >>> ... >>> Advice to implementors. Although MPI places no requirements on the >>> interaction with external mechanisms such as signal handlers, it is >>> strongly recommended that the routines in this section to read, write, >>> and reset performance variables should be safe to call in asynchronous >>> contexts. Examples of asynchronous contexts include signal handlers >>> and interrupt handlers. Such safety permits the development of >>> sampling-based tools. High quality implementations should strive to >>> make the results of any such interactions intuitive to users, and >>> attempt to document restrictions where deemed necessary. (End of >>> advice to implementors.) >>> -------8<------- >>> >>> MPI has been careful in the past to leave signal safety and signal >>> handling as a quality of implementation issue (see MPI-2.2 pp22:14, >>> pp23:36, pp24:24, and pp384:45). I think that this was a wise >>> decision and that we should carry it forward into new versions of the >>> MPI Standard. I believe that with my proposed text implementations >>> will almost always support signal safety, excepting situations where >>> it is too difficult or impossible to do so. >>> >>> Alternatively, the current MPIT text is incompatible with MPI-2.2 >>> section 2.7 (and probably elsewhere). At the very least a proposal to >>> change that (perfectly good, IMO) text is needed. >>> >>> -Dave >>> >> >> William Gropp >> Deputy Director for Research >> Institute for Advanced Computing Applications and Technologies >> Paul and Cynthia Saylor Professor of Computer Science >> University of Illinois Urbana-Champaign >> >> >> >> >> _______________________________________________ >> Mpi3-tools mailing list >> Mpi3-tools(a)lists.mpi-forum.org >> http://*lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools >> > > ________________________________________________________________________ > Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulzm > CASC @ Lawrence Livermore National Laboratory, Livermore, USA > > > > _______________________________________________ > Mpi3-tools mailing list > Mpi3-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools

1 0