This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Patch, Fortran] PR 55548: SYSTEM_CLOCK with integer(8) provides nanosecond resolution, but only microsecond precision (without -lrt)
On Sun, Dec 2, 2012 at 3:19 PM, Janus Weil <janus@gcc.gnu.org> wrote:
> 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?
Hi,
this looks better than the first path, IMHO. I worry slightly that a
changing count rate could confuse users, but OTOH I agree you have a
point in that the current behavior can give users a false impression
of better accuracy than what is actually provided.
An issue with the idea of changing count rate is that using an OS API
providing some particular resolution doesn't in itself guarantee that
the underlying hardware clock is actually capable of that resolution.
But I suppose there's not much we can do about that anyway (if one has
clock_gettime, one probably also has clock_getres, but at least on
Linux that seems to always return 1 ns as the resolution).
Unless somebody else has objections, together with a documentation
patch and a ChangeLog entry, this is Ok for trunk.
(As a follow-up, somebody familiar with Windows could provide some
info on what the resolution there is, and can we do something to
improve our current implementation; e.g. do both mingw and cygwin
provide gettimeofday() or do we really fall back to time()? )
>
> 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.
--
Janne Blomqvist