[J3] SYSTEM_CLOCK

[Steven G. Kargl]

On Sat, Jan 30, 2021 at 10:16:20AM +0000, John Reid via J3 wrote:
> Vipul Parekh wrote:
> > 
> > 
> > On Fri, Jan 29, 2021 at 11:00 AM John Reid via J3
> > <j3 at mailman.j3-fortran.org <mailto:j3 at mailman.j3-fortran.org>> wrote:
> > 
> >     ..
> >     Your idea of basing everything on a real R for the count rate on an
> >     image would not work for an old code using default integers on an
> >     image
> >     that has a fast clock.  ..
> > 
> > John,
> > 
> > I am very much bothered by the sentence, "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."
> > All,
> > 
> > My experience is limited to a *single* clock on an image that is
> > generally fast but which the implementors might view as being too fast
> > relative to 32-bit integer counts.  So the processor might try to be
> > "smart" and attempt some scaling of the tick counts to serve as a good
> > timer for the calling program when the integer arguments are 32-bit
> > and/or when they are of larger bit-size.  Under the circumstances, it
> > does seem the count rate becomes an arbitrary value such as 1,000 or
> > 10,000 or 1,000,000 to simply help with the scaling.  Conceptually such
> > an arbitrary fixed value for the tick rate comes across as no different
> > than CLOCKS_PER_SEC in <time.h> with the C processor that usually has an
> > arbitrary constant value of 1,000,000,000.  Or even the HZ constant with
> > 'jiffies' on Linux kernel timers.
> 
> Very interesting! I took it as a fact that some processors have more than
> one clock and that we needed to address this.
> 
> The history of SYSTEM_CLOCK is summarized in my draft reply. Until F 2018,
> the model was of a single clock. I think we made the change to allow for
> different images having different clocks and still thought of each image
> having a single clock. Some 20 years ago (F 2003) we recognized that some
> systems needed long integers and simply assumed that on such
> systems users would use long integers.
> 
> So how about now requiring long integers on such a system?
> 

On operating systems that support IEEE Std 1003.1b-1993 (“POSIX.1b”)
and have the clock_gettime() system call, gfortran has offered two
clock rates for at least a decade.  The selection of which clock
rate to use is essentially based on the minimum numeric storage size
of the the actual arguments in a SYSTEM_CLOCK reference.

Intel Fortran offers two clock rates.  I do not use Intel Fortran,
so can offer a date for when it starting offering two.

NAG's compiler seems to offer only a single clock rate.

In principle, I think the current wording of the Fortran standard
allows more than two clock rates on a processor; although, I am
uncertain how a programmer could choose a specific clock rate 
if 3 or more exists.  It seems a SYSTEM_CLOCK_QUERY([NUMBER],[RATES])
intrinsic subroutine is needed to enumerate the clock rates, and
SYSTEM_CLOCK() given a new CLK argument to allow a user to select
a specific clock rate.  This is certainly beyond the scope of
an interpretation request.  

-- 
Steve