Implementation Issues

It is clear that an interface for performance measurements must be very efficient and must minimize its influence on the dynamic behavior of the user code under investigation. We designed our POMP library interface with efficiency in mind from the very beginning:

• We choose to define a larger set of performance monitoring API functions according to the pattern

  

  instead of using an interface like

  

  which would have been much simpler to implement. But it would make it necessary to use costly IF or SWITCH statements inside the pomp_event routine, resulting in run-time overhead.

• Argument passing overhead is minimized (while still supporting full context information) by using context descriptors. This was already discussed in Section 3.5.

• If further optimization is required, inlining of the POMP interface calls through the use of macros would be possible. In C/C++, this is possible without any changes to the proposal as outlined above as the function call and macro call syntax is the same. Fortran OpenMP instrumentation only requires the generation of the CALL keyword during OpenMP directive transformation to be suppressed. However, the structure of a single POMP call is so simple (i.e., a function call with one constant argument) that current compiler technology should be able to inline the calls without the ``manual'' use of macros.

• The granularity of OpenMP constructs can be much finer than, for example, MPI functions. This is especially true for the ATOMIC, CRITICAL, MASTER, and SINGLE OpenMP constructs as well as for the OpenMP API functions for locking. Implementers of the POMP interface must take special care when implementing the corresponding POMP functions. In addition, we propose that the instrumentation of these constructs can be selectively disabled by specifying the following command line option to the OpenMP compiler or POMP transformation tool:

  

  where construct is the name of one OpenMP construct listed above or "sync" to disable all of them. Finally, if the instrumentation of these (or other) constructs is critical only in specific parts of the code, our !$OMP NOINSTRUMENT directive (see Section 3.7) can be used to disable them selectively.