Reputation: 170
I have some subroutines in my code whos execution time I need to measure. Let's assume the routines are called somewhere from 10-100 times per second in the extreme case. There are many ways to measure time in Fortran, but due to the frequency of the calls I need the one that incurs the lowest amount of overhead.
The time measurement itself does not need to be super accurate, as I'm not interested in the cases when the subroutines take a few milliseconds or less, but rather when they spike to 50ms or more (which is when I need to take counter-action and re-balance some things internally).
The code is parallelized using MPI+OpenMP, so MPI_Wtime()
would be the easiest way, but I guess this one has a pretty large cost associated to it? My guess for a good solution would be system_clock()
. Does anyone know if it's "safe" (performance-wise) to call this 50-100 times per second?
Upvotes: 3
Views: 486
Reputation: 37238
system_clock
is likely significantly cheaper than cpu_time
, and has much better precision.
For GFortran on Linux, I vaguely recall I once tested by calling it in a loop, and system_clock
took on the order of 50 ns per call.
For GFortran on Linux, system_clock
is a wrapper around clock_gettime(CLOCK_MONOTONIC, ...)
, (which on Linux uses a vDSO and not a real syscall so it's very very fast) and so is omp_get_wtime
in libgomp (the OpenMP runtime library that GFortran uses), so the performance for both of these should be more or less the same.
I'm not sure how MPI_Wtime
is implemented on common MPI implementations, but it wouldn't surprise me if it's the same.
Upvotes: 3