290. Miscellaneous Control of Profiling


Up: Logic of the Design Next: Examples Previous: Logic of the Design

There is a clear requirement for the user code to be able to control the profiler dynamically at run time. This is normally used for (at least) the purposes of


These requirements are met by use of the MPI_PCONTROL.

MPI_PCONTROL(level, ...)
IN levelProfiling level
int MPI_Pcontrol(const int level, ...)
MPI_PCONTROL(LEVEL)
INTEGER LEVEL
{ void MPI::Pcontrol(const int level, ...) (binding deprecated, see Section Deprecated since MPI-2.2 ) }
MPI libraries themselves make no use of this routine, and simply return immediately to the user code. However the presence of calls to this routine allows a profiling package to be explicitly called by the user.

Since MPI has no control of the implementation of the profiling code, we are unable to specify precisely the semantics that will be provided by calls to MPI_PCONTROL. This vagueness extends to the number of arguments to the function, and their datatypes.

However to provide some level of portability of user codes to different profiling libraries, we request the following meanings for certain values of level.


We also request that the default state after MPI_INIT has been called is for profiling to be enabled at the normal default level. (i.e. as if MPI_PCONTROL had just been called with the argument 1). This allows users to link with a profiling library and obtain profile output without having to modify their source code at all.

The provision of MPI_PCONTROL as a no-op in the standard MPI library allows them to modify their source code to obtain more detailed profiling information, but still be able to link exactly the same code against the standard MPI library.



Up: Logic of the Design Next: Examples Previous: Logic of the Design


Return to MPI-2.2 Standard Index
Return to MPI Forum Home Page

(Unofficial) MPI-2.2 of September 4, 2009
HTML Generated on September 10, 2009