Hi all,
Our next tools WG meeting is (as usual) on Monday 8/23 (tomorrow) at 8am PDT,
11am EDT, 5pm MSZ. Jeff created a Webex session for us, which is linked on the
tools Wiki. It is:
Password: tools
We have two main item for the agenda: MPIR and MPIT.
MPIR: John requested some time to finish the discussion on the MPIR document before
we turn the document into a standard compliant Latex document and give it for to the
MPI forum forum for review (has to happen by the end of next week).
MPIT: I recently gave a presentation on MPIT to the tools community and I would like to
discuss the feedback from that meeting and its impact on the MPIT proposal. More detail
on this are below.
Talk to you tomorrow / Monday,
Martin
Feedback from the tools community on MPIT (based on CScADS discussions):
(for those of you who were at the CScADS workshop, please feel free to add)
Collection of use cases
Current ideas in MPIT seem to match those use cases very well
High/Low watermarks seen as quite useful
Identification of exhausted resources important
Naming
Several name changes suggested
configuration variables -> control variables (as in OpenMP)
Prefixes:
MPIT_CTRLVARS_...
MPIT_PERFVARS_...
Verbosity levels
Why restrict verbosity from 1 to 5?
Allow a query for the max. verbosity N and then allow levels 1-N
Initialization
Suggestion to remove IsInitialized and IsFinalized
(not useful if we can initialize MPIT multiple times)
Bias towards adding Fortran routines
Need more feedback from the Fortran gurus in the MPI forum
Very strong wish to allow the setting of control variables
In particular autotuning community is very interested and promised to
write up several concrete use cases
How to deal with setting the variables from multiple tools
a) provide lock/unlock routines
b) allow one tool to Initialize MPIT exclusively in MPIT_Init
c) Do nothing and leave races up to tools/users
How to deal with synchronizing variables
Provide additional information during query:
readonly - can never be set
sync/nosync - shows whether a variables is synchronizing or not
communicator - setting a synchronizing variables requires a global
operation on this communicator
(can be MPI_COMM_SELF for nosync variables)
Set routine takes communicator as argument
Must be called by all members of the communicator
Extensibility
Very strong wish to have the option to extend this interface
Tools should have the ability to provide new variables
(this was brought up by several tools groups for various needs)
Seen as essential (not just for Extensibility): Profiling routines for MPIT
Would like to see a different iterator concept:
change from iterators to a list of variables with an integer index
(this fixes the type of the iterator)
Query the number of variables and then provide query routines to ask
for more information on each variable
Restrictions: variables can not be removed or reordered, just added
How to return query information:
Return a struct instead of a list of arguments
Cleaner ways to integrate new information in future versions
Need separate MPIT version constant to guard extensions
Ideally: would like to give MPI an address for a variable to watch and MPI
would then integrate this variable into the MPIT variables
-> easy extension for new variables by external tools through same API
Alternatively: tools can hide this in an PMPIT layer, but then need additional
mechanisms to allocate "dummy" handles to avoid duplicating the handle space
________________________________________________________________________
CASC @ Lawrence Livermore National Laboratory, Livermore, USA