[J3] SYSTEM_CLOCK

[Bill Long]

> On Jan 27, 2021, at 3:11 AM, John Reid via J3 <j3 at mailman.j3-fortran.org> wrote:
> 
> Steven G. Kargl wrote:
>> On Tue, Jan 26, 2021 at 10:06:19PM +0000, John Reid via J3 wrote:
>>> Steve Lionel via J3 wrote:
>>>>   * Add a note warning of unpredictable results if integer kinds are
>>>>     mixed across calls
>>>> 
>>> Do we really have to say anything about doing obviously stupid things like
>>> looking at the difference between COUNT values from different clocks?
>>> 
>> Apparently, yes.  Steve L started to look at SYSTEM_CLOCK due to
>> a post by me in comp.lang.fortran about a gfortran bug report.
> 
>> The user did
>> 
>>    use iso_fortran_env
>> 
>>    integer(int32_t) rate
>>    integer(int64_t) cnt1, cnt2
>> 
>>    call system_clock(count=cnt1, count_rate=rate)
>>    ....
>>    call system_clock(count_cnt2)
>>    print *, (cnt2 - cnt1) / real(rate)
> 
> Well, he was not  looking at the difference between COUNT values from different clocks and this code would be picked up at compile time with the suggested changes because of different integer kinds in a single call of SYSTEM_CLOCK
> 

The declaration for RATE could have just as easily been type REAL, in which case comparing KIND values might not work  This is why I prefer using BIT_SIZE for the restriction.  Of course, the first call to system_clock could have been split into 2 calls, with one argument each, and get around any rules about comparing arguments within a single call. 

Separate problem: the named constants int32_t and int63_t are not part of iso_fortran_env (the _t annexations should not be there), so the code would probably not compile anyway. 

The real problem is that the user is doing a time-in-seconds computation using counts obtained from calls to system_clock that are linked to clock counts that increment at potentially different clock rates than the one used in the expression denominator.  For that the programmer deserves a sharp rap on the knuckles with the “don’t do that” ruler   Perhaps an explanatory NOTE in the standard would be appropriate. 

Cheers,
Bill


> Cheers,
> 
> John.
>> 
>> The problem is that gfortren supports 2 clock rates, and decides
>> which one to use via min(kind(cnt1), kind(rate)).  For this
>> example, the first call returns cnt1 in a millisecond time scale
>> and rate of 1000.  The second call returns cnt2 on a nanosecond
>> time scale.  As SYSTEM_CLOCK returns the number of ticks relative
>> to some reference (say, UNIX epoch), the value of cnt2 far exceeds
>> cnt1.  Thus, (cnt2 - cnt1) / 1000 was nanosecond count divided by
>> millisecond rate.
>> 
>> gfortran documents its processor-dependent behavior, but the
>> bug reporter maintains gfortran has a bug because it does
>> not match Intel Fortran.
>> 
> 

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