Bill Long longb at cray.com
Tue Jan 26 21:40:15 UTC 2021

The general problem for SYSTEM_CLOCK is that it was designed to return the actual value of the processor’s real-time clock, and that is still what people expect.  What has changed is that processors have gotten faster (i.e. the clock tick is much shorter) and in some cases the rate is no longer constant.    The increase in the count rate has made 32-bit integer arguments almost completely useless.  Fortunately, the standard now requires support for 64-bit integers, so that is not a practical issue.  In practice, I almost never see use of a COUNT variable that is not a 64-bit integer.  

To accommodate 32-bit arguments, the COUNT returned is the actual clock value divided by a large number (to prevent immediate roll-over), and the large number is hopefully a large power of 2 so the divide can be implemented as a shift.  This allows the implementation to preserve the assumption that calling system_clock involves essentially zero overhead so it can be used to time short sections of code.   The count_rate and count are always the same size in bits in practice, and by common assumption, even though the standard does not explicitly require this.  So, to get the count_rate for a 64-bit COUNT, call system_clock with either an integer(int64) or real(real64) argument for COUNT_RATE. 

> On Jan 26, 2021, at 1:03 PM, Steve Lionel via J3 <j3 at mailman.j3-fortran.org> wrote:
> The biggest issue I see is that SYSTEM_CLOCK can be called with just a single argument but it takes two or more calls to do something useful.

I don't agree with that characterization.  The vast majority of calls to system_clock have only one argument - the COUNT argument. 
> That COUNT_RATE can be REAL is an additional complication, as the standard cannot possibly impose any restriction on how that relates to integer kinds used for the other arguments.

Why not? We have bit_size as an intrinsic. 

> Note also that a program might be timing two or more different segments, and there's no reason to force them all to use the same clock.

There is only one clock from the user’s point of view.  The question is how the value of that clock is accessed and what its characteristics are. 

> Here is the best I can think of...
> 	• Say that it is processor-dependent whether there is more than one clock (each with their own set of COUNT_RATE and COUNT_MAX values)

The only reason for “more that one clock” is to allow the processor to supply a constant tick clock in addition to a variable-rate “actual” clock.  Even so, to be useful, the constant-tick clock has to be roughly as fast as the typical speed of the real clock, or the usefulness of system_clock is lost. 

> 	• For processors that do have more than one clock, the selection is keyed off of the integer kind of COUNT if it is present. If COUNT is not present but COUNT_MAX is present, the integer kind of COUNT_MAX is used to select. If COUNT_RATE is supplied but not COUNT or COUNT_MAX, and it is an integer, its kind is used to select. Otherwise the default integer kind is used for selection.  (So REAL kinds for COUNT_RATE have no effect on selection - this may conflict with some implementations.)

COUNT_MAX is almost never used because 64-bit counts are the norm.  The COUNT_RATE size in bits (real or integer) DOES matter.  Claiming otherwise would be horribly backwards incompatible. 

> 	• Add a constraint that if more than one integer argument is supplied in a call, all must be of the same integer kind (potential incompatibility)

That would probably not break any existing codes.  On the other hand, calling with more than one integer argument is very rare.  (must -> shall)

> 	• Add a note warning of unpredictable results if integer kinds are mixed across calls
> 	• Add a note recommending that processors document the relationship of RATE and MAX to the various integer kinds

Documentation is always a good idea. But it can be simplified to the point of recommending always using 64-bit arguments. 


> This really is an unholy mess. I suppose it needs an interp.
> Steve
> On 1/26/2021 1:21 PM, John Reid via J3 wrote:
>> Steve, 
>> Where are you with this? I think it can be argued that it was an oversight not to require the integer kinds to agree and propose an interp. to fix this. I think we could also say that a particular kind always addresses the same clock. 
>> Cheers, 
>> John. 
>> Steve Lionel via J3 wrote: 
>>> A week ago I opened a topic in the J3 forum (SYSTEM_CLOCK - J3 Work Items (j3-fortran.org) <https://j3-fortran.org/forum/viewtopic.php?f=9&t=69>) about issues with SYSTEM_CLOCK. I'd appreciate it if others would read this and offer their opinions on what should or could be done. I'll write the paper, but at this point I don't know what to write! 
>>> I'll also ask that J3 members set up the options to be notified when there are new posts in the forum - instructions are at https://j3-fortran.org/forum/viewtopic.php?p=3#p3 The more discussion we have between meetings, the more we can get done at meetings. Thanks. 
>>> Steve 

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

More information about the J3 mailing list