Martin: One correction -- the OpenMP term is "internal control variables" or "ICVs". Bronis On Sun, 22 Aug 2010, Martin Schulz wrote:
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:
https://*cisco.webex.com/ciscosales/j.php?ED=145066572&UID=0&PW=NMjcyNzAwZmU... 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
Control variables 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
________________________________________________________________________ Martin Schulz, [email protected], http://*people.llnl.gov/schulzm CASC @ Lawrence Livermore National Laboratory, Livermore, USA