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