[J3] SYSTEM_CLOCK

[Vipul Parekh]

Dear John,

Thank you for the draft interp, a good start.

Please note a significant issue with SYSTEM_CLOCK intrinsic, as worded in
the current standard, is with respect to the change introduced in Fortran
2003 that allowed COUNT_RATE argument, which is OPTIONAL as well as
INTENT(OUT), to be a REAL scalar.  This is further compounded by the
"processor-dependent" phraseology in the wording that makes it
difficult for practitioners of Fortran to consume the intrinsic reliably in
their codes.  From what I can understand, your draft interp does *not*
address this issue with COUNT_RATE as a real scalar.  Can you please take
this into consideration?

Note the issue with COUNT_RATE as a real scalar and the implementation in
gfortran processor that led to a PR, the discussion surrounding the PR that
apparead online, and which then caught the attention of Steve Lionel can be
summarized *better* with the following short Fortran program:

--- begin code ---
   use iso_fortran_env, only : int64, real32, real64

   integer(int64) :: t1, t2, t3, t4
   real(real32) :: count_rate_r32

   integer, parameter :: n = 2048
   real(real64), allocatable :: a(:,:), b(:,:), c(:,:)

   allocate( a(n,n), b(n,n), c(n,n) )
   call random_number( a )
   call random_number( b )

   call system_clock( t1, count_rate_r32 )
   c = matmul( a, b )
   call system_clock( t2 )

   print *, "t2: ", t2
   print *, "t1: ", t1
   print *, "count_rate_r32: ", count_rate_r32

   print *, "Time: Count Rate as real32: ", (t2 - t1)/count_rate_r32, "
seconds."

end
--- end code ---

Upon execution, the program output using gfortran is:
--- begin output ---
 t2:         3022269212990
 t1:             302209812
 count_rate_r32:    1000.00000
 Time: Count Rate as real32:    3.02196685E+09  seconds.
--- end output ---

The practitioner who submitted the PR with a code snippet such as above
states, that per his/her understanding, the verbiage in the current Fortran
standard does not support the behavior where the basis for clock COUNT when
the OPTIONAL COUNT_RATE is included on the argument list is *different*
from the second call where the OPTIONAL COUNT_RATE is omitted.  Note the
values of 't1' and 't2' in the above shown program output.  However the
gfortran developer disagrees with the practitioner.

Note if the same exact program above is processed with another
implementation (IFORT Classic in Intel oneAPI), the program output is a
more reasonable behavior:
--- begin Intel output ---
 t2:       1611847179768000
 t1:       1611847178191000
 count_rate_r32:    1000000.
 Time: Count Rate as real32:    1.577000      seconds.
--- end output ---

The resultant situation with the practitioner and gfortran is indeed the
"unholy mess" as mentioned by Steve Lionel.  Meaning the wording in the
standard is inadequate to resolve the matter satisfactorily for the
practitioner.

Can the interp address this core issue involving COUNT_RATE as a real
scalar and when this argument is omitted?

Thank you for your attention,
VIpul Parekh

On Thu, Jan 28, 2021 at 7:32 AM John Reid via J3 <j3 at mailman.j3-fortran.org>
wrote:

> Dear all,
>
> Here is a draft interp. Comments, please.
>
> John.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20210128/cbb7159b/attachment.htm>