[Mpi3-tools] MPIT profiling

[Martin Schulz]

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
> jsquyres at cisco.com
> For corporate legal information go to:
> http://BLOCKEDwww.BLOCKEDcisco.com/web/about/doing_business/legal/cri/
> 
> 
> _______________________________________________
> Mpi3-tools mailing list
> Mpi3-tools at lists.mpi-forum.org
> http://BLOCKEDlists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools
> 

________________________________________________________________________
Martin Schulz, schulzm at llnl.gov, http://people.llnl.gov/schulzm
CASC @ Lawrence Livermore National Laboratory, Livermore, USA