[Mpi3-tools] MPIT profiling

[Martin Schulz]

Hi Jeff, all,

On Oct 18, 2010, at 9:13 AM, Jeff Squyres wrote:

> We ran out of time before finishing the discussion today...
> 
> My take on section 1.2.8 of the MPIT document is that it's weird/inconsistent that we're saying that you can use a PMPIT interface to profile the MPIT interface, and that it basically behaves exactly like PMPI.  

I don't think profiling is the right word here - we want to intercept
the MPIT interface and alter its functionality. The fact that the
PMPI interface is known as the profiling interface is actually
kind of unfortunate (I realize this describes the initial purpose);
it is used for so much more by today's tools.

> 
> I claim that this is inconsistent with the MPIT's goal of allowing multiple tools to be active in a single executable -- what if multiple tools want to use the PMPIT interface?  You can't do that without using an external thingy (like PNMPI -- which would need to be expanded to support the MPIT interface).

I don't agree with this - the MPIT interface could be used inside
the MPI application, e.g., to read and document configurations 
or to set specific runtime parameters. Further, individual application
libraries/components could include their own measurement calls 
(for self monitoring and tuning). This means that there could be 
multiple "users" of the MPIT interface even without writing a single 
PMPI tool.

By allowing PMPIT, we would enable tools that add to the offering
of MPIT for all the above users. 

Additionally, I think adding the PMPIT interface option keeps the
MPIT interface in line with the MPI interface, which I think is
important to gain acceptance. This was also the feedback from
the tools community that feels *very* strongly about maintaining
the profiling interface for all of the MPI standard, incl. MPIT.

> 
> Meaning: since supporting multiple tools in a single executable is an explicit goal, we should either allow MPIT profiling by multiple tools within a single process or we shouldn't allow it at all.

I don't think this is necessary and covered by the current proposal.
>From a tool developers perspective, we can do everything we want/
need to do with the current proposal.

> 
> Background:
> 
> Two use cases for profiling MPIT cited on the call were:
> 
> 1. Martin: Tools adding their own control / performance variables.  My suggestion here is that maybe we can have a registration functionality for this (i.e., an MPIT function to register new control/performance variables).  I have not thought this through deeply; my only point is that if we know tool writers want to do something (and Martin says that the tool writers do want to do it), then we should provide them a direct way to do it.  Not an indirect way.

We discussed this during the tools workshop and then 
decided to drop it. The requirements for such a registration
seemed to get out of hand quickly (who tracks the variables,
who handles starts and stops, who manages the sessions -
and all this for variables that we don't know yet), while the 
PMPIT interface had all the necessary features for tool
developers. 

Additionally, even with a registration function there was a very
clear opinion towards includinh the PMPIT interface. The question 
was basically why not do it, since the PMPI interface has proven to
be so widely successful and used for so much more than
originally anticipated. How can we ensure that we cover 
everything with a registration function? This may not be the only
use case in the future (e.g., we would need interception for FT
layers that restore state on restart, and I am sure we can find
more use cases).

Martin


> 
> 2. Marty: It is worthwhile to be able to profile the impact of MPIT itself -- e.g., see if MPIT itself is performing poorly.  I extrapolate this to mean that it can be useful to help quantify the at least part of the MPIT's own overhead (as I typed that sentence, I'm not sure how much of MPIT's overhead will be measurable by simply timing how long its individual function calls...?  I guess there's other metrics that can be measured, too...?).  
> 
> -- 
> Jeff Squyres
> jsquyres at cisco.com
> For corporate legal information go to:
> http://BLOCKEDwww.BLOCKEDcisco.com/web/about/doing_business/legal/cri/
> 
> 
> _______________________________________________
> Mpi3-tools mailing list
> Mpi3-tools at lists.mpi-forum.org
> http://BLOCKEDlists.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