[Mpi3-tools] Next Tools WG Meeting 8/23 - MPIR & MPIT

[Bronis R. de Supinski]

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=NMjcyNzAwZmU2&RT=MiMxMQ%3D%3D
> 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, schulzm at llnl.gov, http://*people.llnl.gov/schulzm
> CASC @ Lawrence Livermore National Laboratory, Livermore, USA
>
>
>
>