[Mpi3-tools] New MPIT draft available / Question regarding Verbosity

Sun Feb 21 04:13:20 CST 2010

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 ..." -> "<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.

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 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
>
> _______________________________________________
> Mpi3-tools mailing list
> Mpi3-tools at lists.mpi-forum.org
> http://*lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools
>

________________________________________________________________________
Martin Schulz, schulzm at llnl.gov, http://people.llnl.gov/schulzm
CASC @ Lawrence Livermore National Laboratory, Livermore, USA