[J3] SYSTEM_CLOCK

[Vipul Parekh]

On Sat, Jan 30, 2021 at 5:16 AM John Reid <John.Reid at stfc.ac.uk> wrote:

> .. Until F2018, the model was of a single clock. I think we made the
> change to
> allow for different images having different clocks and still thought of
> each image having a single clock.  ..
>

John,

I apologize for my repetition.

The model with F2018, based simply on a reading of 18-007r1, does
come across as that of a single clock on an image.  Not just that: the
"API" of the intrinsic with 3 optional arguments, each of them intent(out)
and thus providing no way to input anything to the intrinsic, remains as
that of a single count rate of the clock.  The example provided in the
standard document of some clock with an arbitrary count rate reinforces
this.  Thus most programmers will gain the impression SYSTEM_CLOCK works
with a single clock with an arbitrary but fixed count rate that depends on
the processor.

And even though both your drafts address better the following scenario:

--- usage 1 --
!     t1 and t2 are of the same integer kind
call system_clock( t1, rate )
    ! some instructions
call system_clock( t2 )
calc_time = real( t2-t1, kind=K ) / real( rate, kind=K )
--- end usage 1 ---

there is still a problem with usage 2 which can't be resolved even with
"requiring long integers" given the option of a real scalar for COUNT_RATE.

--- begin usage 2 ---
  !     t1 and t2 are of the same integer kind
call system_clock(  COUNT_RATE=rate ) ! then store the rate for later use
..
call system_clock( COUNT=t1 )
   .. ! some instructions
call system_clock( COUNT=t2 )
cpu_time = real( t2-t1, kind=K ) / real( rate, kind=K )
--- end usage 2 ---

But now both the above usages can work when the processors employ a single
count rate.  NAG compiler appears to support this.

I suggest rewording the interp to simply reinforce what the standard
informs most readers i.e., a single count rate with a single clock on an
image.

It does not appear the standard, as per its current wording, got to the
point of conveying more than one clock on an image.  It will be better for
the interp to not introduce any such notion of more than one clock on an
image - that can be a Fortran 202Y item?

Regards,
Vipul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20210130/3604b6b4/attachment-0003.htm>