[Mpi3-tools] MPIT profiling

[Jeff Squyres]

On Oct 22, 2010, at 11:58 AM, Martin Schulz wrote:

>> 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.

Ok.

>> 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.

Did you mean PMPIT?

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

But you only allow *one* tool per process to do this.  That's the inconstancy: there could be multiple consumers of the MPIT interface, but you're only allowing *one* tool to use the "profiling" side of the MPIT interface (or whatever you want to call it).

In short: if we allow multiple consumers of the MPIT interface, why not also allow multiple users of the "profiling" side of the MPIT interface?

>> 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.

Aren't we going to be in exactly the same sucky position we're in right now with PMPI -- that you can only have *one* tool that provides this functionality per process?

>> 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).

...doesn't these future uses also anticipate the need to have more than one user of the profiling side of the MPIT interface?

-- 
Jeff Squyres
jsquyres at cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/