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

Martin Schulz schulzm at llnl.gov
Mon Aug 23 11:38:30 CDT 2010


Hi all,

Since we had to end quickly today, just a few organizational things  
via email:

- The notes from today's meeting are online - please feel free to add  
if necessary.
- We didn't cover the last part of the MPIT discussion, so please send  
any comments
   via email (preferably this week) so that I can create a new draft  
of the MPIT document
- We will need to get the MPIR document to the MPI forum by the end of  
the week,
   hence if there are any comments left, please send them asap
- The meeting in two weeks is canceled due to Labor day
- The next meeting is on 9/20 at the usual time - the agenda will be  
to cover any
   open issues on MPIR raised during the forum meeting the week before  
and to
   start going over the new MPIT draft.

Martin



On Aug 22, 2010, at 2:58 PM, 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
>
>
>

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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-tools/attachments/20100823/c25cc675/attachment-0001.html>


More information about the mpiwg-tools mailing list