Need higher resolution times for linpack benchmark

[Tim Prince]

Delbert Franz wrote:
>  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. 
In ifort, the hook is the choice of integer type. Rate is 10000 for 
32-bit and 1000000 for 64-bit integer.