[J3] SYSTEM_CLOCK

[Bill Long]

> On Jan 28, 2021, at 1:46 PM, Vipul Parekh via J3 <j3 at mailman.j3-fortran.org> wrote:
> 
> 
> 
> On Thu, Jan 28, 2021 at 1:23 PM Steven G. Kargl via J3 <j3 at mailman.j3-fortran.org> wrote:
> ..
> Does it matter that you don't see a justification?  The Fortran
> standard permits a Fortran processor to select a clock rate based
> on its actual arguments.  gfortran does
> 
>    k = min(kind(COUNT), kind(COUNT_RATE), kind(COUNT_MAX))
>    if (k < 4) no clock
>    if (k == 4) millisecond time scale
>    if (k > 4) nanosecond time scale
> 
> This, in a nutshell, is the crux of the problem for the poor persevering practitioners of  Fortran.
> 
> The "processor-dependent" clauses in the standard *seemingly* give leeway to the implementors to do whatever!
> 
> With the relationship shown above, particularly " k = min(kind(COUNT), kind(COUNT_RATE), kind(COUNT_MAX)) " and " if (k == 4) millisecond time scale", some imponderables faced by the practitioner who raised the PR will be:
> 
> 1) What does the KIND of a real variable have anything to do with the KIND of an integer variable?

The numerical values of KINDs are vendor determined.  gfortran can use the KIND values it assigns , knowing what those values are, in a formula inside the compiler or its library.  I think that gfortran should employ their IF branches separately for each argument, rather than forming a MIN( ).    Also, converting the actual hardware clock to milliseconds or nanoseconds seems expensive.  For k > 4 I would return the actual hardware clock count or rate.  For k = 4, scaling the actual clock rate by 2**20 would be a lot faster than scaling ia nanosecond version by 10**6. 

Almost all vendors use the size in bytes for the KIND values for integer and real types. So, while the values are technically processor-dependent, there is little variation about what is done. 


> 
> 2) Consider ISO_FORTRAN_ENV and its named constants toward INT32 with integer that may be KIND=4 in some processor and REAL32 for real which may also be KIND=4 under the separate real KINDS list with said processor: how are they to be treated equivalently in a relationship such as above given the different numerical models for integers and reals?
> 

I think you answered your own question.  For most implementations INT32 and REAL32 have the same value.  And gfortran can rely on that equality for their computation. 


> 3) Considering 2, why would COUNT in INT64 and COUNT_RATE as REAL32 result in "millisecond time scale" whereas COUNT only in INT64 leads to "nanosecond time scale" for the clock rate?

As noted above, I think using the MIN computation is a mistake. 

Cheers,
BIll

> 
> Cheers,
> Vipul Parekh
> 
> 

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