[Mpi3-tools] MPIT_PERFORMANCE_ALL and layering
Martin Schulz
schulzm at llnl.gov
Sun Feb 21 02:24:05 CST 2010
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
> Mpi3-tools at lists.mpi-forum.org
> http://*lists.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
More information about the mpiwg-tools
mailing list