[J3] SYSTEM_CLOCK

[Vipul Parekh]

Re: "Intel conforms to this now, but gfortran does not. I see no
justification for the gfotran behaviour."  I agree entirely.  But gfortran
developer does not and essentially points to the "processor-dependent"
wording in the standard as a "long rope" to do whatever while the
practitioner gets shot in the foot.

Hence the question is whether the wording in the standard can be adequately
improved to help with real-life problems faced by practitioners.

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." can help whenever a practitioner fetches the
COUNT_RATE *in conjunction with* the COUNT.   However, the practitioner
faces the risk of an inconsistent, processor-dependent mess should they
fetch the COUNT_RATE separately with a real scalar.  The intrinsic with 3
optional arguments and the revised wording still do not quite point the
practitioner adequately in the right direction.

Can a NOTE be added which informs the reader what Bill and others have
pointed out earlier?  A NOTE such that for a useful consumption of this
intrinsic, it is advised to employ INT64 integer kind for COUNT argument;
and, either INT64 integer kind or REAL64 real kind for COUNT_RATE.  But the
COUNT_RATE with a real scalar case should be fetched with one of the other
2 integer arguments - COUNT or COUNT_MAX - being present in the calls with
integer arguments having the same integer kind of INT64 as expected in
subsequent SYSTEM_CLOCK calls with the single argument COUNT.

Thanks,
Vipul Parekh


On Thu, Jan 28, 2021 at 10:56 AM John Reid <John.Reid at stfc.ac.uk> 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.
>
> 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.
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20210128/768160e4/attachment.htm>