Hi Dave, On Feb 16, 2010, at 3:35 PM, Dave Goodell wrote:
I think that we should reconsider including MPIT_PERFORMANCE_ALL as it currently exists in the MPIT proposal because it discourages libraries and layering among performance tools. If you have two tool libraries and one or both of them use MPIT_PERFORMANCE_ALL to start/stop their performance variables, the tools are likely to be incompatible. One of MPI's great strengths is providing support mechanisms for parallel libraries, I don't see why we should omit those mechanisms in the tools space.
I agree, this is a good point. I removed the use of MPIT_PERFORMANCE_ALL from the document (at least for now).
I understand the convenience and (potentially) performance arguments to be made for having functionality like this, but we might want to consider scoping it sort of like we do for communicators. Perhaps make it possible to group handles or open handles with an associated context of sorts to perform the group start/stop operations later.
Alternatively, if there is no substantial performance argument to be made, we could just drop MPIT_PERFORMANCE_ALL altogether. A for- loop isn't particularly burdensome to tools/applications.
I don't have a concrete alternative proposal here, I just wanted to bring up the issue for discussion. I unfortunately missed the last concall due to technical difficulties, so I wasn't able to bring it up there.
There are two ideas that make a MPIT_PERFORMANCE_ALL approach usable: one could allow users to define groups of performance variables that can then be started and stopped together. However, this would require a new set of routines and would make the interface quite a bit more complicated. The other idea, that Marty brought up in last week's TelCon, is to manage separate instances of the MPIT interface. In this case, MPIT_Init would return a handle that is then passed to any subsequent routine. In this case, the ALL constant would only apply to all performance variables queried and instantiated under the handle of the current instance. However, also this makes the API significantly more complex and also changes the semantics of the Init routine to no longer be parallel to MPI_Init. Perhaps it is the easiest and best just to drop the ALL constant and require users to use for loops to work with the variables. Martin
-Dave
_______________________________________________ Mpi3-tools mailing list [email protected] http://*lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools
________________________________________________________________________ Martin Schulz, [email protected], http://people.llnl.gov/schulzm CASC @ Lawrence Livermore National Laboratory, Livermore, USA