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 [email protected] For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/