This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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






Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]