Need higher resolution times for linpack benchmark

[Janne Blomqvist]

On Sat, Dec 12, 2009 at 02:19, Tobias Burnus <burnus@net-b.de> wrote:
> In principle, SYSTEM_CLOCK would, if count_rate is/were large enough,
> cf. http://gcc.gnu.org/onlinedocs/gfortran/SYSTEM_005fCLOCK.html
>
> Internally, it uses POSIX's clock_gettime (when available), which in
> principle provides sub-ms resolution.

Actually, it doesn't. It prefers to use gettimeofday() which provides
1 us resolution, falling back to time() with 1s resolution. In
practice, I believe gettimeofday() is available more or less
everywhere. With clock_gettime() we could get in principle up to 1 ns
resolution (With Linux 2.6.31 I got around 60 -> 800 ns depending in
which timer I used), however the downside of that is that it's not as
ubiquitous and if it exists it lives in librt or libposix depending on
platform, so we'd need some configure magic to handle that and link in
those libraries.

> However, I think for INTEGER(4) and
> for INTEGER(8) the clock_rate should be the same; if so, one cannot make
> it too high, otherwise count wraps round all the time for INTEGER(4).

I disagree. Code which assumes some specific value for clock_rate is
broken anyway, as can be seen by the fact that other compilers use
different values.

Hence, see the attached patch, which makes clock_rate = 1e6 for the
integer(8) version, giving 1 us resolution.  As mentioned above, if we
need more, we need to use clock_gettime(). Also, it removes an unused
argument from the gettimeofday() call. Ok for trunk (with a ChangeLog,
of course)?

> I think we should consider to change the rate from 1000 (->25d) to 10000
> (->60h).

I don't know; 60h is pretty easy to overflow for some long-running calculation.

>(And finally support non-integer clock_rates, cf. PR 28484.)

Yes. However since the actual implementation has no need for real
clock rates, this is IMHO best achieved by having the frontend use a
temporary integer variable and then copying back the result to the
real variable.

Similarly, F2003 allows any integer kinds in any combination, and to
support that without a combinatorial explosion of library functions,
we need to use temp variables and copying in the frontend. Of course,
this applies to a lot of other intrinsics as well.

Also, see the attached C++ file for a simple test for different timing
functions. For me, a typical runs looks like

Testing clock()
avg/min/max: 10/10/10 ms.
Testing times()
_SC_CLK_TCK: 100
Real time Avg/Min/Max: 8.7/0/10 ms.
User time Avg/Min/Max: 2.8/0/10 ms.
Sys time Avg/Min/Max: 3.5/0/10 ms.
Testing getrusage()
User time Avg/min/max: 9.7/0/10 ms.
System time avg/min/max: 33.8/0/210 ms.
Testing gettimeofday()
Wall time avg/min/max: 1/1/1 us.
Testing clock_gettime() with CLOCK_MONOTONIC
Clock avg/min/max: 74.48/67/752 ns.
Testing clock_gettime() with CLOCK_REALTIME
Clock avg/min/max: 66.31/65/91 ns.
Testing clock_gettime() with CLOCK_PROCESS_CPUTIME_ID
Clock avg/min/max: 171.33/169/381 ns.
Testing clock_gettime() with CLOCK_THREAD_CPUTIME_ID
Clock avg/min/max: 157.73/156/217 ns.

As can be seen, the CPU time accounting functions give around 10 ms
resolution. One thing we could consider would be using times() instead
of getrusage() in order to avoid the large system time overhead of
getrusage(). clock_gettime() with  *CPUTIME_ID provides rather better
CPU time resolution, but unfortunately suffers from the usual problems
associated with using rdtsc on SMP systems.


-- 
Janne Blomqvist
-------------- next part --------------
A non-text attachment was scrubbed...
Name: clocktest.cpp
Type: text/x-c++src
Size: 4766 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20091213/5e6fbc52/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: system_clock.diff
Type: text/x-patch
Size: 1902 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20091213/5e6fbc52/attachment-0001.bin>