Hi Jeff, [cut some text]

...

...

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?

Yes, I was seeing them as one.

...

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?

Personally, I would love to do that - basically standardizing PnMPIT, but this would make the interface much more complex and does add some overhead in any case - I don't think there is a way around that. I doubt we would get a majority for this (perhaps I am wrong about that?). Also, it would either no longer be the same approach that we have done with MPI/PMPI or we would have to change that as well - that probably will find even less acceptance. Don't we have the same issue with MPI as well, though: multiple components, libraries, communicators using the MPI interface, but only one tool can use the PMPI 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?

I wouldn't call it sucky - there is a solution around it that solves the problem without having to change the standard and without causing overhead in the default case (and I got a few papers out of it ;) ). Sure, having it in the MPI standard would be a bit nicer/cleaner, but at what cost? I don't think this would be an easy interface to define. Martin

...

...

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

_______________________________________________ Mpi3-tools mailing list [email protected] http://BLOCKEDlists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools

________________________________________________________________________ Martin Schulz, [email protected], http://people.llnl.gov/schulzm CASC @ Lawrence Livermore National Laboratory, Livermore, USA