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

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

On Sat, Dec 1, 2012 at 1:17 PM, Janus Weil <janus@gcc.gnu.org> wrote:
> 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 ...

No, not Ok.

IIRC there was some discussion about COUNT_RATE back when the
nanosecond resolution system_clock feature was developed, and one idea
was to have different count rates depending on whether clock_gettime
is available, as you also suggest in the PR. In the end it was decided
to keep a constant count rate as a consistent rate was seen as more
important than "wasting" a few of the least significant bits when
nanosecond resolution is not available, since int8 has sufficient
range for several centuries even with nanosecond resolution. Anyway, I
don't feel particularly strongly about this, and if there now is a
consensus to have a changing count rate, I can live with that.

But, I do object to providing only microsecond resolution for the int8
version. Nanosecond resolution is indeed not necessary in most cases,
but like the saying goes, "Precision, like virginity, is never
regained once lost.". Reducing the resolution is a regression for
those users who have relied on this feature; I, for one, have several
test and benchmark programs which depend on nanosecond resolution for
the int8 system_clock. OTOH, if one wants a microsecond count rate,
converting the count value is just a single statement following the
system_clock call.

Needing to link with librt in order to access clock_gettime is an
unfortunate wart in glibc, but other C libraries exist out there
(heck, given the success of Android, glibc is certainly a minority
even if you limit yourself to Linux), and of those that provide
clock_gettime, most have it directly in libc and not in a separate
library.

As for the int16 and int2 variants, F2003 requires that the arguments
can be of any kind. AFAICS, this means that different arguments can be
of different kind. So in order to avoid a combinatorial explosion, the
only sensible way is for the frontend to create temporaries of
suitable kind, then call an appropriate library function etc. As
mentioned, int8 already provides several centuries range with
nanosecond resolution, and thus I see no reason to provide a int16
version, but rather the frontend should create int8 temporaries, call
system_clock_8, then copy the results back to the actual int16
arguments. F2003 requires than all supported kinds should work, which
would include kinds 1 and 2, although those versions obviously suffer
from a lack of either range, precision or both, to the extent that
they are quite useless in practice. I think they could be handled by
just setting count to -huge(), count_rate and count_max to 0 in the
frontend and not bothering to make a library call at all. Also, F2003
specifies than COUNT_RATE can be of type real as well; I think this
should be handled similarly, by the frontend copying the result from
an integer temporary. So in the end I don't think we need new library
entry points, but rather the temporary variable handling stuff in the
frontend.

-- 
Janne Blomqvist