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

[Mpi3-tools] New MPIT draft / Next Meeting
by Martin Schulz 21 Feb '10

21 Feb '10

Hi all, I uploaded a new draft of the MPIT interface to the tools WK wiki at: https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/MPI3Tools/draft This includes all comments I got so far (thanks!). Our next TelCon is Monday at the usual time (8am PT, 11am CT, 5pm MEZ) - here is the WebEx link, which is also available on the WG tools web site. https://cisco.webex.com/ciscosales/j.php?ED=132799527&UID=0&PW=NZTA1NTViMWV… As part of the agenda, I would like to gather additional feedback on the MPIT interface as well as to talk about how far the other debugging proposals are. Further, we need to get ready for the face to face meeting, especially if this is supposed to have a focus on tools. Martin ________________________________________________________________________ Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulzm CASC @ Lawrence Livermore National Laboratory, Livermore, USA

1 0

Re: [Mpi3-tools] New MPIT draft available / Question regarding Verbosity
by Martin Schulz 21 Feb '10

21 Feb '10

Hi Tobias, all, Thanks for the comments - I added most of them into the document, a few comments or questions below. Martin On Feb 10, 2010, at 11:10 PM, Tobias Hilbrich wrote: > Hi Martin, Hi group, > > its great to see the first versions of a proposal, I went over it > and tried to find issues and errors. As I am unfortunately only > rarely able to join the telco, I may raise issues that had already > been discussed, if so feel free to ignore these comments. > > p7, line 3: "Fortran bindings are not required." -> One might give a > rational for that, which is I guess that this targets tools that are > usually not written in Fortran. I am beginning to think that we should provide the usual Fortran bindings, since there may be good reasons to call this from the application, which can be Fortran. Comments? > > p7, line 35: Uses "MPIT_Init" to refer to "MPIT_INIT" (consistency > change) (also in line 41) > > p8, line 4-6: "Once this routine is called no MPIT routine ... may > be called ...." -> I would add an except MPIT_INITIALIZED and > MPIT_FINALIZED > > p9: general comment to MPIT_Datatype: A MPIT_DATATYPE_NULL might > make the design more consistent to the regular MPI_Datatype design ... Hmm, what would that mean? > > p9, line 32: "MPI_MAX_ENUMTYPE" -> "MPIT_MAX_ENUMTYPE" > > p11, line 18/19: IN iterator -> INOUT iterator > > p11 general comment to names: "MPIT_CONFIG_QUERY" and > "MPI_Configquery_iterator" seem not very consistent There are two options to fix this: get rid if the _ in the routine name, which makes the routine's name out of sync with the rest, or to add an _ into the type declaration. Both options don't seem good to me. Therefore, I am leaving this as is - please object if you feel strongly about this. > > p11 general comment on iterators: > * Is there a strong need to use distinct iterator types for the > config query and the performance query, couldn't we use a > MPIT_Iterator type instead ? Optimization might be harder if the MPI stores the two things separately. Also, the information returned is different (in case the type is just a pointer to a corresponding struct). > * MPIT_CONFIG_QUERY and MPIT_PERFORMANCE_QUERY might also set the > iterator to MPIT_[ITERATOR|CONFIGQUERY|PERFORMANCEQUERY]_END when > the call returns an MPIT_END (for consistency with common iterator > concepts) OK. > > p12, line 8: "MPIT_CONFIG_INFO(name, type, ...)" -> > "MPIT_CONFIG_INFO(name, datatype, count, ...)" > > p12 comments on "MPIT_CONFIG_INFO": > * Strictly seen, when the user may set desc to NULL, I would define > desc as INOUT > * What is the value of desclen when the user sets desc to NULL ? This would impact many more calls and I am not sure if this is consistent with the rest of the MPI standard. Anybody else have any opinions here? > > p13, line 33: "...the appropriate sized and ..." -> "...the > appropriate size and ..." > > p16, line 18: "IN set string to a set" -> "string to a set" > is not very descriptive, what about "string identifier of a set" or > something similar ? > > p16, line 35: "that explains in the use ..." -> "that explains the > use ..." > > p16, line 38: "name and description, are ..." -> "name and > desc, are ..." > > p16, line 39: "A conforming MPI implementation may not ... " -> "A > conforming MPI implementation must not ... " > > p16, line 41: "MPIT_PERFORMANCE_QUERY may ..." -> "MPIT_GET_SETINFO > may ..." (same in line 46!) > > p16, line 44: "MPI_MAX_SET_NAME" -> "MPIT_MAX_SET_NAME" > > p16, general comment about MPIT_GET_SETINFO: > * Strictly seen, when the user may set desc to NULL, I would define > desc as INOUT > (Same holds for further calls, I stopped listing all of them) > > p17, line 2: "MPI_MAX_SET_DESC" -> "MPIT_MAX_SET_DESC" > > p17, line 15: IN iterator iterator .... -> INOUT .... > > p17 comment about naming: "MPIT_PERFORMANCE_QUERY" vs > "MPIT_Performancequery_iterator" > > p17, line 43: "The parameter name is used to return a short and > unique name for the performance variable found." -> "The parameter > name is used to return a short and unique name for the performance > variable found, which is used as its identifier in other calls to > the MPIT performance interface." > > p17, line 44: "A conforming MPI implementation may not..." -> "A > conforming MPI implementation must not ..." > > p18, line 4: "MPI_MAX_PERFORMANCEVAR_NAME" -> > "MPIT_MAX_PERFORMANCEVAR_NAME" > > p18, line 47: "MPI_MAX_PERFORMANCEVAR_DESC" -> > "MPIT_MAX_PERFORMANCEVAR_DESC" > > p19, line 10: "MPI_MAX_PERFORMANCEVAR_SETS(???)" -> > "MPIT_MAX_PERFORMANCEVAR_SETS(???)" > > p19, general comment to naming of MPIT Performance interface calls: > * binding names like "MPIT_Performance_changed ()" seem to suggest a > totally different behavior than they actually implement, in fact the > MPIT_Performance is meant as a sort of namespace here why not use > MPIT_PERFORMANCE_Changed to denote that, or if this is inconsistent > with the rest of the standard (which apparently is the case), then > why not use an extra word here, e.g. MPIT_Performance_vars_changed. Yes, that makes sense. I changed it to the latter. > > p19, comment to MPIT_Performancehandle: > * none of the other MPI handles use "handle" as part of their name, > so what about "MPIT_Performance[_]var" ? Hmm, this would make it quite generic, but I do see your point. What do other's think about this. > * what about a MPIT_PERFORMANCE[HANDLE/VAR]_NULL for consistency > with the other MPI handles ? I am not sure what this will help. In the main MPI this documents completion - something that we don't have here. > * One might add that the user of the MPIT interface should free all > performance handles before calling MPIT_FINALIZE > * MPIT_PERFORMANCE_ALL is inconsistent with other constant handles > (that use the handle name as their base name. e.g. MPI_Comm -> > MPI_COMM_WORLD), what about MPIT_PERFORMANCE[HANDLE|VAR]_ALL I removed that all together after Dave's comment. > > p21, line 33: "MPIT_ERR_PERFORANCE_WRITE" -> "MPIT_PERFORMANCE_WRITE" > > > -Tobias > > > Martin Schulz wrote: >> Hi all, >> >> I uploaded a new draft of the MPIT proposal to >> >> https://*svn.mpi-forum.org/trac/mpi-forum-web/wiki/MPI3Tools/draft >> >> Changes since the last draft are marked with changebars and are >> colored in green. >> The latest draft contains changes based on comments from Kathryn >> Mohror and >> the MPI group at Sun/Oracle. >> >> There is one open question that I would like to bring up for a >> general discussion: >> as discussed in the WG earlier, we need some kind of verbosity >> parameter that >> allows the MPI implementation to classify each variable according >> to its importance >> and general usage scenario. Jeff and I have been going forth and >> back on this >> one for a while over email, but we can't come to a useful >> conclusion and hence >> would like wider feedback. >> >> In general, we both think that we want 5 classes of verbosity (odd >> number larger >> than 3, but not too large). >> >> The original proposal had the following classes >> VERY_HIGH >> HIGH >> MEDIUM >> LOW >> VERY_LOW >> which was rejected by the forum (I think rightfully so) since it >> doesn't really convey >> any useful application level information. >> >> The current proposal has: >> USER_BASIC >> USER_DETAILED >> TUNER_BASIC >> TUNER_DETAILED >> MPI_IMPLEMENTOR >> with the idea that the first two classes are intended for general >> MPI users, >> the third and fourth for performance experts and system >> administrators >> wishing to tune the performance of MPI itself, while the fifth is >> for MPI >> implementors and would include debugging information. >> >> Open MPI uses a similar idea of verbosity and defines the following >> five classes: >> INFORMATION >> TRIVIAL >> MINOR >> MAJOR >> CRITICAL >> However, both Jeff and I don't like these classes, since they don't >> convey >> any useful information either. >> >> Jeff proposes something like >> BASIC >> ? >> ADVANCED >> ? >> INTERNAL >> but this proposal misses good names for 2 and 4. >> >> Any comments or suggestions (either extending one of the above or >> completely >> new) would be very much appreciated. >> >> Thanks, >> >> Martin >> >> >> ________________________________________________________________________ >> 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 >> > > > -- > Tobias Hilbrich > GWT - TUD GmbH > Chemnitzer Straï¿½e 48b > 01187 Dresden > Tel.: +49 351 463 35876 > Fax: +49 351 463 37773 > http://*www.*gwtonline.de > > Geschï¿½ftsfï¿½hrer: Claus-Peter Held > Prokuristin: Beate-Victoria Ermisch > Die GWT ist eingetragen beim Amtsgericht Dresden - HRB: 13 840 > > _______________________________________________ > 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

1 0

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

21 Feb '10

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? 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

1 0

Re: [Mpi3-tools] MPIT_PERFORMANCE_ALL and layering
by Martin Schulz 21 Feb '10

21 Feb '10

Hi Dave, On Feb 16, 2010, at 3:35 PM, Dave Goodell wrote: > I think that we should reconsider including MPIT_PERFORMANCE_ALL as > it currently exists in the MPIT proposal because it discourages > libraries and layering among performance tools. If you have two > tool libraries and one or both of them use MPIT_PERFORMANCE_ALL to > start/stop their performance variables, the tools are likely to be > incompatible. One of MPI's great strengths is providing support > mechanisms for parallel libraries, I don't see why we should omit > those mechanisms in the tools space. I agree, this is a good point. I removed the use of MPIT_PERFORMANCE_ALL from the document (at least for now). > > I understand the convenience and (potentially) performance arguments > to be made for having functionality like this, but we might want to > consider scoping it sort of like we do for communicators. Perhaps > make it possible to group handles or open handles with an associated > context of sorts to perform the group start/stop operations later. > > Alternatively, if there is no substantial performance argument to be > made, we could just drop MPIT_PERFORMANCE_ALL altogether. A for- > loop isn't particularly burdensome to tools/applications. > > I don't have a concrete alternative proposal here, I just wanted to > bring up the issue for discussion. I unfortunately missed the last > concall due to technical difficulties, so I wasn't able to bring it > up there. There are two ideas that make a MPIT_PERFORMANCE_ALL approach usable: one could allow users to define groups of performance variables that can then be started and stopped together. However, this would require a new set of routines and would make the interface quite a bit more complicated. The other idea, that Marty brought up in last week's TelCon, is to manage separate instances of the MPIT interface. In this case, MPIT_Init would return a handle that is then passed to any subsequent routine. In this case, the ALL constant would only apply to all performance variables queried and instantiated under the handle of the current instance. However, also this makes the API significantly more complex and also changes the semantics of the Init routine to no longer be parallel to MPI_Init. Perhaps it is the easiest and best just to drop the ALL constant and require users to use for loops to work with the variables. Martin > > -Dave > > _______________________________________________ > 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

1 0

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

17 Feb '10

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

1 0

[Mpi3-tools] MPIT_PERFORMANCE_ALL and layering
by Dave Goodell 16 Feb '10

16 Feb '10

I think that we should reconsider including MPIT_PERFORMANCE_ALL as it currently exists in the MPIT proposal because it discourages libraries and layering among performance tools. If you have two tool libraries and one or both of them use MPIT_PERFORMANCE_ALL to start/stop their performance variables, the tools are likely to be incompatible. One of MPI's great strengths is providing support mechanisms for parallel libraries, I don't see why we should omit those mechanisms in the tools space. I understand the convenience and (potentially) performance arguments to be made for having functionality like this, but we might want to consider scoping it sort of like we do for communicators. Perhaps make it possible to group handles or open handles with an associated context of sorts to perform the group start/stop operations later. Alternatively, if there is no substantial performance argument to be made, we could just drop MPIT_PERFORMANCE_ALL altogether. A for-loop isn't particularly burdensome to tools/applications. I don't have a concrete alternative proposal here, I just wanted to bring up the issue for discussion. I unfortunately missed the last concall due to technical difficulties, so I wasn't able to bring it up there. -Dave

1 0

[Mpi3-tools] alternative signal handler text
by Dave Goodell 16 Feb '10

16 Feb '10

(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

1 0

Re: [Mpi3-tools] New MPIT draft available / Question regarding Verbosity
by Tobias Hilbrich 11 Feb '10

11 Feb '10

Hi Martin, Hi group, its great to see the first versions of a proposal, I went over it and tried to find issues and errors. As I am unfortunately only rarely able to join the telco, I may raise issues that had already been discussed, if so feel free to ignore these comments. p7, line 3: "Fortran bindings are not required." -> One might give a rational for that, which is I guess that this targets tools that are usually not written in Fortran. p7, line 35: Uses "MPIT_Init" to refer to "MPIT_INIT" (consistency change) (also in line 41) p8, line 4-6: "Once this routine is called no MPIT routine ... may be called ...." -> I would add an except MPIT_INITIALIZED and MPIT_FINALIZED p9: general comment to MPIT_Datatype: A MPIT_DATATYPE_NULL might make the design more consistent to the regular MPI_Datatype design ... p9, line 32: "MPI_MAX_ENUMTYPE" -> "MPIT_MAX_ENUMTYPE" p11, line 18/19: IN iterator -> INOUT iterator p11 general comment to names: "MPIT_CONFIG_QUERY" and "MPI_Configquery_iterator" seem not very consistent p11 general comment on iterators: * Is there a strong need to use distinct iterator types for the config query and the performance query, couldn't we use a MPIT_Iterator type instead ? * MPIT_CONFIG_QUERY and MPIT_PERFORMANCE_QUERY might also set the iterator to MPIT_[ITERATOR|CONFIGQUERY|PERFORMANCEQUERY]_END when the call returns an MPIT_END (for consistency with common iterator concepts) p12, line 8: "MPIT_CONFIG_INFO(name, type, ...)" -> "MPIT_CONFIG_INFO(name, datatype, count, ...)" p12 comments on "MPIT_CONFIG_INFO": * Strictly seen, when the user may set desc to NULL, I would define desc as INOUT * What is the value of desclen when the user sets desc to NULL ? p13, line 33: "...the appropriate sized and ..." -> "...the appropriate size and ..." p16, line 18: "IN set string to a set" -> "string to a set" is not very descriptive, what about "string identifier of a set" or something similar ? p16, line 35: "that explains in the use ..." -> "that explains the use ..." p16, line 38: "name and description, are ..." -> "name and desc, are ..." p16, line 39: "A conforming MPI implementation may not ... " -> "A conforming MPI implementation must not ... " p16, line 41: "MPIT_PERFORMANCE_QUERY may ..." -> "MPIT_GET_SETINFO may ..." (same in line 46!) p16, line 44: "MPI_MAX_SET_NAME" -> "MPIT_MAX_SET_NAME" p16, general comment about MPIT_GET_SETINFO: * Strictly seen, when the user may set desc to NULL, I would define desc as INOUT (Same holds for further calls, I stopped listing all of them) p17, line 2: "MPI_MAX_SET_DESC" -> "MPIT_MAX_SET_DESC" p17, line 15: IN iterator iterator .... -> INOUT .... p17 comment about naming: "MPIT_PERFORMANCE_QUERY" vs "MPIT_Performancequery_iterator" p17, line 43: "The parameter name is used to return a short and unique name for the performance variable found." -> "The parameter name is used to return a short and unique name for the performance variable found, which is used as its identifier in other calls to the MPIT performance interface." p17, line 44: "A conforming MPI implementation may not..." -> "A conforming MPI implementation must not ..." p18, line 4: "MPI_MAX_PERFORMANCEVAR_NAME" -> "MPIT_MAX_PERFORMANCEVAR_NAME" p18, line 47: "MPI_MAX_PERFORMANCEVAR_DESC" -> "MPIT_MAX_PERFORMANCEVAR_DESC" p19, line 10: "MPI_MAX_PERFORMANCEVAR_SETS(???)" -> "MPIT_MAX_PERFORMANCEVAR_SETS(???)" p19, general comment to naming of MPIT Performance interface calls: * binding names like "MPIT_Performance_changed ()" seem to suggest a totally different behavior than they actually implement, in fact the MPIT_Performance is meant as a sort of namespace here why not use MPIT_PERFORMANCE_Changed to denote that, or if this is inconsistent with the rest of the standard (which apparently is the case), then why not use an extra word here, e.g. MPIT_Performance_vars_changed. p19, comment to MPIT_Performancehandle: * none of the other MPI handles use "handle" as part of their name, so what about "MPIT_Performance[_]var" ? * what about a MPIT_PERFORMANCE[HANDLE/VAR]_NULL for consistency with the other MPI handles ? * One might add that the user of the MPIT interface should free all performance handles before calling MPIT_FINALIZE * MPIT_PERFORMANCE_ALL is inconsistent with other constant handles (that use the handle name as their base name. e.g. MPI_Comm -> MPI_COMM_WORLD), what about MPIT_PERFORMANCE[HANDLE|VAR]_ALL p21, line 33: "MPIT_ERR_PERFORANCE_WRITE" -> "MPIT_PERFORMANCE_WRITE" -Tobias Martin Schulz wrote: > Hi all, > > I uploaded a new draft of the MPIT proposal to > > https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/MPI3Tools/draft > > Changes since the last draft are marked with changebars and are > colored in green. > The latest draft contains changes based on comments from Kathryn > Mohror and > the MPI group at Sun/Oracle. > > There is one open question that I would like to bring up for a general > discussion: > as discussed in the WG earlier, we need some kind of verbosity > parameter that > allows the MPI implementation to classify each variable according to > its importance > and general usage scenario. Jeff and I have been going forth and back > on this > one for a while over email, but we can't come to a useful conclusion > and hence > would like wider feedback. > > In general, we both think that we want 5 classes of verbosity (odd > number larger > than 3, but not too large). > > The original proposal had the following classes > VERY_HIGH > HIGH > MEDIUM > LOW > VERY_LOW > which was rejected by the forum (I think rightfully so) since it > doesn't really convey > any useful application level information. > > The current proposal has: > USER_BASIC > USER_DETAILED > TUNER_BASIC > TUNER_DETAILED > MPI_IMPLEMENTOR > with the idea that the first two classes are intended for general MPI > users, > the third and fourth for performance experts and system administrators > wishing to tune the performance of MPI itself, while the fifth is for MPI > implementors and would include debugging information. > > Open MPI uses a similar idea of verbosity and defines the following > five classes: > INFORMATION > TRIVIAL > MINOR > MAJOR > CRITICAL > However, both Jeff and I don't like these classes, since they don't > convey > any useful information either. > > Jeff proposes something like > BASIC > ? > ADVANCED > ? > INTERNAL > but this proposal misses good names for 2 and 4. > > Any comments or suggestions (either extending one of the above or > completely > new) would be very much appreciated. > > Thanks, > > Martin > > > ________________________________________________________________________ > 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 > -- Tobias Hilbrich GWT - TUD GmbH Chemnitzer Straï¿½e 48b 01187 Dresden Tel.: +49 351 463 35876 Fax: +49 351 463 37773 http://www.gwtonline.de Geschï¿½ftsfï¿½hrer: Claus-Peter Held Prokuristin: Beate-Victoria Ermisch Die GWT ist eingetragen beim Amtsgericht Dresden - HRB: 13 840

1 0

Re: [Mpi3-tools] New MPIT draft available / Question regarding Verbosity
by Martin Schulz 08 Feb '10

08 Feb '10

Hi Marc-Andre, On Feb 8, 2010, at 12:46 AM, Marc-Andre Hermanns wrote: > Martin, > > although not part of the MPIT chapter, the first page (chapter > 1.2.1) on > line 32/33 seems to be missing a verb. The sentence ends right after > the > "... as macros (See Section x)." and I would expect a phrase like "can > be intercepted". Thanks for finding this - this is part of the existing profiling interface text and needs a separate change procedure. I started collecting these and I will add this one to my list. Thanks, Martin > > Best regards, > Marc-Andre > > PS: I had to remove the color option of the changebars package > becaus of > some "option name clash" regarding "color". Without the option is > compiles fine. Strange - the annotated MPI standard already uses color. I will see if I can fix this. > > Martin Schulz wrote: >> Hi all, >> >> I uploaded a new draft of the MPIT proposal to >> >> https://*svn.mpi-forum.org/trac/mpi-forum-web/wiki/MPI3Tools/draft >> >> Changes since the last draft are marked with changebars and are >> colored in green. >> The latest draft contains changes based on comments from Kathryn >> Mohror and >> the MPI group at Sun/Oracle. >> >> There is one open question that I would like to bring up for a >> general >> discussion: >> as discussed in the WG earlier, we need some kind of verbosity >> parameter that >> allows the MPI implementation to classify each variable according to >> its importance >> and general usage scenario. Jeff and I have been going forth and back >> on this >> one for a while over email, but we can't come to a useful conclusion >> and hence >> would like wider feedback. >> >> In general, we both think that we want 5 classes of verbosity (odd >> number larger >> than 3, but not too large). >> >> The original proposal had the following classes >> VERY_HIGH >> HIGH >> MEDIUM >> LOW >> VERY_LOW >> which was rejected by the forum (I think rightfully so) since it >> doesn't really convey >> any useful application level information. >> >> The current proposal has: >> USER_BASIC >> USER_DETAILED >> TUNER_BASIC >> TUNER_DETAILED >> MPI_IMPLEMENTOR >> with the idea that the first two classes are intended for general MPI >> users, >> the third and fourth for performance experts and system >> administrators >> wishing to tune the performance of MPI itself, while the fifth is for >> MPI >> implementors and would include debugging information. >> >> Open MPI uses a similar idea of verbosity and defines the following >> five classes: >> INFORMATION >> TRIVIAL >> MINOR >> MAJOR >> CRITICAL >> However, both Jeff and I don't like these classes, since they don't >> convey >> any useful information either. >> >> Jeff proposes something like >> BASIC >> ? >> ADVANCED >> ? >> INTERNAL >> but this proposal misses good names for 2 and 4. >> >> Any comments or suggestions (either extending one of the above or >> completely >> new) would be very much appreciated. >> >> Thanks, >> >> Martin >> >> >> ________________________________________________________________________ >> 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 > > > -- > 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 > _______________________________________________ > 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

1 0

Re: [Mpi3-tools] New MPIT draft available / Question regarding Verbosity
by Marc-Andre Hermanns 08 Feb '10

08 Feb '10

Martin, although not part of the MPIT chapter, the first page (chapter 1.2.1) on line 32/33 seems to be missing a verb. The sentence ends right after the "... as macros (See Section x)." and I would expect a phrase like "can be intercepted". Best regards, Marc-Andre PS: I had to remove the color option of the changebars package becaus of some "option name clash" regarding "color". Without the option is compiles fine. Martin Schulz wrote: > Hi all, > > I uploaded a new draft of the MPIT proposal to > > https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/MPI3Tools/draft > > Changes since the last draft are marked with changebars and are > colored in green. > The latest draft contains changes based on comments from Kathryn > Mohror and > the MPI group at Sun/Oracle. > > There is one open question that I would like to bring up for a general > discussion: > as discussed in the WG earlier, we need some kind of verbosity > parameter that > allows the MPI implementation to classify each variable according to > its importance > and general usage scenario. Jeff and I have been going forth and back > on this > one for a while over email, but we can't come to a useful conclusion > and hence > would like wider feedback. > > In general, we both think that we want 5 classes of verbosity (odd > number larger > than 3, but not too large). > > The original proposal had the following classes > VERY_HIGH > HIGH > MEDIUM > LOW > VERY_LOW > which was rejected by the forum (I think rightfully so) since it > doesn't really convey > any useful application level information. > > The current proposal has: > USER_BASIC > USER_DETAILED > TUNER_BASIC > TUNER_DETAILED > MPI_IMPLEMENTOR > with the idea that the first two classes are intended for general MPI > users, > the third and fourth for performance experts and system administrators > wishing to tune the performance of MPI itself, while the fifth is for > MPI > implementors and would include debugging information. > > Open MPI uses a similar idea of verbosity and defines the following > five classes: > INFORMATION > TRIVIAL > MINOR > MAJOR > CRITICAL > However, both Jeff and I don't like these classes, since they don't > convey > any useful information either. > > Jeff proposes something like > BASIC > ? > ADVANCED > ? > INTERNAL > but this proposal misses good names for 2 and 4. > > Any comments or suggestions (either extending one of the above or > completely > new) would be very much appreciated. > > Thanks, > > Martin > > > ________________________________________________________________________ > 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 -- 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