[J3] SYSTEM_CLOCK

[John Reid]

Vipul Parekh via J3 wrote:
> 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?

I have already done this. My proposed wording for [420:16] is "If an 
image has more than one  clock, the clock is determined by the kind of 
the integer  arguments or is processor dependent if there are no 
integer  arguments. "

In your example,
        call system_clock( t1, count_rate_r32 )
will get the count rate for the intended clock.

Intel conforms to this now, but gfortran does not. I see no 
justification for the gfotran behaviour.

Cheers,

John.



>
> 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 <mailto:j3 at mailman.j3-fortran.org>> wrote:
>
>     Dear all,
>
>     Here is a draft interp. Comments, please.
>
>     John.
>