Since parts of the MPI library may themselves be implemented using
more basic MPI functions (e.g. a portable implementation of the
collective operations implemented using point to point communications),
there is potential for profiling functions to be called from within an
MPI function
that
was called from a profiling function. This could
lead to ``double counting'' of the time spent in the inner routine.
Since this effect could actually be useful under some circumstances
(e.g. it might allow one to answer the question ``How much time is
spent in the point to point routines when they're called from
collective functions ?''), we have decided not to enforce any
restrictions on the author of the MPI library
that
would overcome
this. Therefore the author of the profiling library should be aware of
this problem, and guard against it herself. In a single threaded
world this is easily achieved through use of a static variable in the
profiling code
that
remembers if you are already inside a profiling
routine. It becomes more complex in a multi-threaded environment (as
does the meaning of the times recorded !)
The Unix linker traditionally operates in one pass : the effect of this
is that functions from libraries are only included in the image if
they are needed at the time the library is scanned. When combined with
weak symbols, or multiple definitions of the same function, this can
cause odd (and unexpected) effects.
Consider, for instance, an implementation of MPI in which the Fortran
binding is achieved by using wrapper functions on top of the C
implementation. The author of the profile library then assumes that it
is reasonable only to provide profile functions for the C binding,
since Fortran will eventually call these, and the cost of the wrappers
is assumed to be small. However, if the wrapper functions are not in
the profiling library, then none of the profiled entry points will be
undefined when the profiling library is called. Therefore none of the
profiling code will be included in the image. When the standard MPI
library is scanned, the Fortran wrappers will be resolved, and will
also pull in the base versions of the MPI functions. The overall
effect is that the code will link successfully, but will not be
profiled.
To overcome this we must ensure that the Fortran wrapper functions are
included in the profiling version of the library. We ensure that this
is possible by requiring that these be separable from the rest of the
base MPI library. This allows them to be ared out of the base
library and into the profiling one.
Up: Complications
Next: Linker Oddities
Previous: Complications
288.2. Linker Oddities
Up: Complications
Next: Multiple Levels of Interception
Previous: Multiple Counting
Up: Complications
Next: Multiple Levels of Interception
Previous: Multiple Counting
Return to MPI-2.1 Standard Index
Return to MPI Forum Home Page
MPI-2.0 of July 1, 2008
HTML Generated on July 6, 2008