Page tree

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


For this and the other topics below, please consult the slides for details.  What follows is jut a brief overview.  Jim began by saying that GTPL was designed for analyzing the performance of large parallel (MPI/OpenMP) jobs but it might also be useful for the unit testing functionality described above.  It is written in C and can be used for C, C++, and Fortran code.   The GTPL libraries utilizes the PMPI library which provides a profiling layer for MPI. It can run in two different modes.  The first is through explicit sentinels - code modifications that start and stop the profile timers for specific sections of code . The second mode is auto-instrumentation that uses compiler-generated entry and exit points enabled with the "-finstrument-functions" compiler option.   Yannick asked if the user can mix these two modes and Jim responded yes - the example on the slides demonstrates this.


Clementine asked whether one can get performance summaries for a subset of tasked MPI tasks and Jim responded yes - one can pass an MPI communicator to the summary function to get information for a particular group.  Mark O asked about overhead.  Jim responded that one of the significant sources of overhead can be to call the intrinsic gettimeofday() routines to do the timings.  When called many times, potentially billions of times in a large application,  this can add up.  Jim avoids this when possible.  Mark O mentioned accessing the hardware counters through, for example, the papi library.  Jim agreed this can be useful if you're careful about how the hardware counters are reset.  In any case, the overhead will depend on how many times a particular sentinel is called.


Steve V mentioned that he has used the MAP tool from Arm FORGE on Cheyenne and finds it to be very useful and easy to use.  But, being proprietary and GUI-heavy, this might make it unsuitable for incoporating incorporating into our CI testing.

Ryan did give a brief description of the intel tools.  He mentioned that these are freely available (note error in Mark M's meeting announcement that said these required an intel license - they do not).  Jim R added that these tools can be extremely useful.  He mentioned in particular a racing race condition in threads that was quickly diagnosed with inspector that would have been very difficult to track down otherwise.

It was mentioned that OOPS has timers that are in use now which provide coarse timing information (basically the total time for each test). It might make sense to start with these timing data for experimenting with automatic timing analysis during unit testing.

The meeting closed with a reminder from Yannick to please suggest more topics for focused JEDI meetings in the future.  You can do this by sending an email to one of us on the core team or by directly editing the JEDI Bi-weekly Discussion ZenHub board.