[J3] SYSTEM_CLOCK

[Bill Long]

> On Jan 28, 2021, at 9:56 AM, John Reid via J3 <j3 at mailman.j3-fortran.org> wrote:
> 
> 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.

I see no justification for the Intel behavior.  If you supply a 32-bit argument for COUNT_RATE you should reasonably expect to receive back the rate for the 32-bit clock. Any edits to the standard should be consistent with this expectation.  I suspect the gfortran behavior is the common one. 

Cheers,
Bill

> 
> 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.
>> 
> 

Bill Long                                                                       longb at hpe.com
Engineer/Master , Fortran Technical Support &   voice:  651-605-9024
Bioinformatics Software Development                      fax:  651-605-9143
Hewlett Packard Enterprise/ 2131 Lindau Lane/  Suite 1000/  Bloomington, MN  55425