Hi Jeff, all, On Oct 18, 2010, at 9:13 AM, Jeff Squyres wrote:
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 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.
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. By allowing PMPIT, we would enable tools that add to the offering of MPIT for all the above users. Additionally, I think adding the PMPIT interface option keeps the MPIT interface in line with the MPI interface, which I think is important to gain acceptance. This was also the feedback from the tools community that feels *very* strongly about maintaining the profiling interface for all of the MPI standard, incl. MPIT.
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.
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.
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). Martin
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://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