Re: Relaxing argument requiremens on SYSTEM_CLOCK

[Janne Blomqvist <blomqvist dot janne at gmail dot com>]

On Sat, Jun 7, 2014 at 6:38 PM, Steve Kargl
<sgk@troutmask.apl.washington.edu> wrote:
> On Sat, Jun 07, 2014 at 04:36:47PM +0200, FX wrote:
>> > The standard says that "it is is assigned a processor-dependent
>> > approximation to the number of processor clock counts per second, or
>> > zero if there is no clock."  Given modern hardware where cpu throttling
>> > is common, it would seem to me that the clock rate can varying.

I think it means "processor" as per the Fortran standard definition of
the term rather than the vernacular definition.  Certainly the
intention cannot be that the clock rate would vary with the cpu clock
rate, as the intention clearly is that system_clock provides a clock
suitable for wall-time measurements (as opposed to cpu_clock).

>> I agree that CLOCK_RATE can vary in principle, *if something happens
>> to the processor clock*.
>>
>> Right now, in gfortran, suppose you call SYSTEM_CLOCK twice, once
>> with a 32-bit integer, once with a 64-bit integer. The two values
>> of clock rate will differ by 3 orders of magnitude, but there is
>> supposed to be one clock (that?s how the standard reads), which
>> has not varied in the meantime.

I think originally the two versions were due to supporting
-fdefault-integer-8 in Fortran 95. Then when F2003 allowed arbitrary
integer kinds and reals we got the integer(8) version for free (and
now with your patch the rest as well, woo!). Anyway, by my reading of
the standard the current implementation is allowed, "a
processor-dependent value based on the value of the processor clock"
could mean that the "processor-dependent value" depends on the
types/kinds of the arguments, no? Same goes for COUNT_MAX; if it
wasn't allowed to provide a different COUNT_MAX for different kinds,
supporting INTEGER(1) would mean that COUNT_MAX would be 127 for all
the other kinds, which is clearly unusable.

> Oh my.  I just scanned libgfortran/intrinsics/system_clock.c.
> It contains hardcoded values.  It seems that we should be able
> to use clock_getres() (on at least linux/*bsd systems).

Well, struct timespec tv_nsec is in units of nanoseconds, no matter
what clock_getres says. So at worst we might be giving the user a
false sense of more accuracy than is really available, but AFAICS the
calculation should be correct. Secondly, what are we going to do with
the data provided by clock_getres? Unless the resolution happens to be
evenly divisible by all potential tv_nsec values, we'd potentially
lose information by dividing the tv_nsec value with the resolution.
FWIW, on Linux/glibc, AFAIK clock_getres always returns a resolution
of 1 nanosecond, so clock_getres is a bit pointless there.



-- 
Janne Blomqvist