[J3] SYSTEM_CLOCK

[Vipul Parekh]

On Thu, Jan 28, 2021 at 5:07 PM Bill Long via J3 <j3 at mailman.j3-fortran.org>
wrote:

> .. we want to be careful to word something like this ..
>

None of the suggestions, including the draft interp, thus far address the
basic concern of practitioners where they follow a simple idiom as shown
below and get tripped up by incomprehensible program behavior depending on
the type but ALSO kind of rate and t1, t2:
--- begin idiom ---
call system_clock(  COUNT_RATE=rate ) ! then tuck away the rate some place
..
call system_clock( COUNT=t1 )
   .. ! do something
call system_clock( COUNT=t2 )
cpu_time = real( t2-t1, kind=.. ) / real( rate, kind=.. )
--- end idiom ---

I don't see anything in the current standard wording of the standard that
implies the value of arguments be dependent on anything other than what an
image has in terms of a *processor clock*.

Trying to tie the values of the 3 INTENT(OUT) to the 3 optional arguments
is a needless complication, it's even a disservice to the practitioners.

Better will be to have the wording in the standard ascertain that an image
has a certain processor-dependent count rate which is represented as a REAL
scalar in some arbitrary precision, say KIND(1D0).  Now call it 'R' as it
does in the example.  The standard can state 'R' will be zero when the
image has no clock.  Then state the following:

1. COUNT: the value will be INT( t * R, kind=kind(COUNT) ) where 't' is a
suitable representation of the processor clock tick and where 't' itself is
a real scalar of the same kind as R,

2. COUNT_RATE:
    a. the value will be INT( R, kind=kind(COUNT_RATE) ) when COUNT_RATE
argument is an integer scalar,
    b. the value will be REAL( R, kind=kind(COUNT_RATE) ) when COUNT_RATE
argument is a real scalar,

3. COUNT_MAX: the value will be INT( tmax * R - 1, kind=kind(COUNT_MAX) )
where 'tmax' is a suitable representation of the point at which processor
clock tick resets and where tmax is a real scalar of the same kind as R,

Note none of the above 3 bullet points are foreign to the current standard;
they are exactly as implied by the example.  And it is exactly how it works
in practice with most implementations when the KINDs of arguments are such
that they correspond to 64-bit objects.

Having the SYSTEM_CLOCK argument results characterized as above in the 3
bullet points will eliminate the present confusion, make it clear for
practitioners and implementors alike, with little to no impact on existing
code with any useful scenarios involving this intrinsic.

Vipul Parekh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20210128/996df9ec/attachment.htm>