[Mpi3-tools] New MPIT draft available / Question regarding Verbosity
Tobias Hilbrich
Tobias.Hilbrich at zih.tu-dresden.de
Thu Feb 11 01:10:56 CST 2010
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 ..." -> "<b>name</b> and
<b>desc</b>, 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 at llnl.gov, http://people.llnl.gov/schulzm
> CASC @ Lawrence Livermore National Laboratory, Livermore, USA
>
>
>
> _______________________________________________
> Mpi3-tools mailing list
> Mpi3-tools at 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
More information about the mpiwg-tools
mailing list