Re: Need higher resolution times for linpack benchmark

[Steve Kargl <sgk at troutmask dot apl dot washington dot edu>]

On Fri, Dec 11, 2009 at 11:57:25PM +0200, Janne Blomqvist wrote:
> Delbert Franz wrote:
> >Hi,
> >
> >I am running the standard 100x100 LINPACK benchmark program under 
> >Debian Lenny compiled with gfortran 4.3.2.  The results are highly 
> >erratic and stem from all the timers I have tried having an apparent 
> >resolution of one millisecond.  Consequently many of the times are 
> >shown as 0.0 or if non-zero, have so much noise that the results are 
> >useless.  I have tried CPU_TIME, SECOND, and DTIME.  
> >
> >CPU_TIME claims to be able to produce microsecond resolution, but 
> >somehow it does not on my machine.  Running an Intel E8400 chip and 
> >the kernel is compiled with the various high-resolution timers 
> >included.  All of the times printed from CPU_TIME clearly show a 
> >resolution of one millisecond.  
> >
> >Is there a way to get higher resolution than a millisecond from this 
> >version of gfortran?  
> 
> CPU_TIME and other non-standard cpu timer functions are implemented by 
> using getrusage(), which is usually the best available POSIX CPU timer 
> function. The problem is that at least on Linux, it seems that while the 
> getrusage() API as such should be able to provide microsecond 
> resolution, the Linux kernel itself keeps track of CPU time only up to 
> millisecond resolution.

Everyone should switch to FreeBSD. ;-)

> The high-resolution timers in recent Linux kernels you mention don't 
> change the granularity of process CPU time accounting.
> 
> One thing you can do it to use a wall-clock timer instead of a CPU 
> timer. The DATE_AND_TIME intrinsic is implemented with gettimeofday(), 
> which should give you up to microsecond resolution, especially with a 
> modern kernel with the high-resolution timers. There is a PR around for 
> using clock_gettime() instead if available; that API supports nanosecond 
> resolution, although in practice it will be limited by the hardware.

The above doesn't measure cpu time of the process.  It includes
any system time, and possibly any idle while your process sits in
swap.  Of course, I suspect Janne knows this.  

On a slightly different note, if your running an archaic synthetic
benchmark that completes at the resolution of your timing routines,
then you might consider the merits of said benchmark.  That is, 
change the 100x100 matrix size to 1000x1000 or larger as needed.

PS:  if you're really interested in how fast something executes,
then use a profiler, e.g., gprof.

-- 
Steve