[Mpi3-tools] MPIT profiling

[Jeff Squyres]

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

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.

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.

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://www.cisco.com/web/about/doing_business/legal/cri/