I have to agree with Jim, this proposal won't work - I don't want
MPI_COMM_ID(),
to be collective (as this proposal implies).
This an example of a more general problem, typically encountered by debuggers
and similar tools: how to obtain extra information for debugging, without
comprimising performance when debugging is not required. The traditional
approach of having a switch to turn the information gathering on and off
appears to apply.
So one generic solution is to specify certain behaviour for debug hook
functions (like MPI_COMM_ID), only when debugging is enabled. The switch would
probably be an argument to MPI_INIT().
An alternative is to specify the hook functions, but allow their behaviour to
be a "no-op". A debugging complient implementation would support the full
semantics of the functions, while a high performance implementation would only
perform "no-ops". The user would link to the desired version.
One might ask, how is this alternative different from the profiling interface
currently specified by MPI. Consider as a simple example the issue of
obtaining context. One correct, portable way to do this in a profiling wrapper
is to use the profiling interface to intercept all calls which create and
destroy communicators. The profiling wrapper could then create a unique
profiling context-id for the communicator (for example using the algorithms
currently used by MPICH), and cache that context on the communictor.
This approach would certainly work, but it does seem inefficient, given that
many implementations already have a unique context-id underneath. A similar
approach might be possible for obtaining access to types, and other more
complex entities, however, I expect that the code in the profiling wrapper
will become as complex as the code in the implementation, something which
seems undesirable.
So, the alternative provides hooks in to the implementation to gain access to
those hidden attributes which a debugger/profiler is likely to need. The cost
is either:
two builds of the MPI library need to be made, one with debugging/profiling
conditional code enabled, and one with it disabled. This will provide the
best performance, at the cost of additional maintenance of the two
versions.
runtime checks within the MPI library determine whether to support
debugging/profiling. This obviously has a (small?) runtime overhead. For
object creation this overhead seems reasonable (what is the overhead of
a simple test in the scheme of building a new communicator). However, we
may well describe debugging/profiling hooks which require data collection
on each send/recv - operations which desire to be very streamlined.
Lloyd Lewins
Hughes Aircraft Co.
llewins@msmail4.hac.com