This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: Need higher resolution times for linpack benchmark
On Friday 11 December 2009, Tobias Burnus wrote:
> Delbert Franz wrote:
> > Aside from researching how to call the C routine suggested by another
> > response to this question, I don't see any gfortran routine that meets
> > the requirements.
>
> In principle, SYSTEM_CLOCK would, if count_rate is/were large enough,
> cf. http://gcc.gnu.org/onlinedocs/gfortran/SYSTEM_005fCLOCK.html
>
> Internally, it uses POSIX's clock_gettime (when available), which in
> principle provides sub-ms resolution. Currently, gfortran uses
> clock_rate=1000 and thus has "only" ms resultion; ifort and g95 use
> clock_rate=10000. With INTEGER(4) on can describe with clock_rate=1000
> about 25 days, with clock_rate=10000 only 60 hours - and for 100000 its
> just 6h which should be too short for many applications.
>
> Using INTEGER(8) with 1 ns resolution, one can describe 292 years, which
> should be enough for timing reasons. However, I think for INTEGER(4) and
> for INTEGER(8) the clock_rate should be the same; if so, one cannot make
> it too high, otherwise count wraps round all the time for INTEGER(4).
>
> I think we should consider to change the rate from 1000 (->25d) to 10000
> (->60h). (And finally support non-integer clock_rates, cf. PR 28484.)
>
> Tobias
>
>
Your response gave me an idea. I used g95 and found that the default
rate was 10000. However, there is an environment variable, G95_SYSTEM_CLOCK,
with which the user can give the rate. I set the rate to 100000 and I get
stable results from the linpack benchmark. I suggest that there be some
hook so the user can set the value. A rate of 1000 produces erratic
results even on my Acer Aspire One netbook:) For many purposes, timing longer
events, a rate of 1000 is more than enough. No fixed number will work
for all cases--therefore it should be settable by the user as required
by the application.
Just my $0.02 worth (with inflation over the past 46 years of programming,
that should probably be more like $0.15 worth:-) )
Delbert