Re: [Patch, Fortran] PR 55548: SYSTEM_CLOCK with integer(8) provides nanosecond resolution, but only microsecond precision (without -lrt)

[Janus Weil <janus at gcc dot gnu dot org>]

Hi all,

since the first version of my SYSTEM_CLOCK patch was not so well
received, I propose here an alternative patch: It does not use a fixed
COUNT_RATE, but adjusts it to match the resolution of the underlying
library function which is used. For the int4 version it additionally
limits COUNT_RATE to 1000, in order to provide a reasonable maximum
timespan. The patch also has the effect that the reported COUNT_RATE
can now depend e.g. on the linker flags used (as does the precision of
the clock: 1 nanosec with -lrt and 1 microsec without).

Does anyone agree with me that this represents an improvement of the
SYSTEM_CLOCK behavior?

Cheers,
Janus



2012/12/1 Janus Weil <janus@gcc.gnu.org>:
> Hi all,
>
> here is a straightforward patch for the intrinsic procedure
> SYSTEM_CLOCK. It does two things:
> 1) It reduces the resolution of the int8 version from 1 nanosecond to
> 1 microsecond (COUNT_RATE = 1000000).
> 2) It adds an int16 version with nanosecond precision.
>
> The motivation for item #1 was mainly that the actual precision is
> usually not better than 1 microsec anyway (unless linking with -lrt).
> This results in SYSTEM_CLOCK giving values whose last three digits are
> zero. One can argue that this is not a dramatic misbehavior, but it
> has disadvantages for certain applications, like e.g. using
> SYSTEM_CLOCK to initialize the random seed in a Monte-Carlo
> simulation. In general, I would say that the value of COUNT_RATE
> should not be larger than the actual precision of the clock used.
>
> Moreover, the microsecond resolution for int8 arguments has the
> advantage that it is compatible with ifort's behavior. Also I think a
> resolution of 1 microsecond is sufficient for most applications. If
> someone really needs more, he can now use the int16 version (and link
> with -lrt).
>
> Regtested on x86_64-unknown-linux-gnu (although we don't actually seem
> to have any test cases for SYSTEM_CLOCK yet). Ok for trunk?
>
> Btw, does it make sense to also add an int2 version? If yes, which
> resolution? Note that most other compilers seem to have an int2
> version of SYSTEM_CLOCK ...
>
> Cheers,
> Janus
>
>
> 2012-12-01  Janus Weil  <janus@gcc.gnu.org>
>
>     PR fortran/55548
>     * gfortran.map (GFORTRAN_1.5): Add _gfortran_system_clock_16.
>     * intrinsics/system_clock.c (system_clock_8): Change resolution to
>     one microsec.
>     (system_clock_16): New function (with nanosecond resolution).
>
> 2012-12-01  Janus Weil  <janus@gcc.gnu.org>
>
>     PR fortran/55548
>     * intrinsic.texi (SYSTEM_CLOCK): Update documentation of SYSTEM_CLOCK.
>
> 2012-12-01  Janus Weil  <janus@gcc.gnu.org>
>
>     PR fortran/55548
>     * gfortran.dg/system_clock_1.f90: New test case.

Attachment: pr55548_v2.diff
Description: Binary data