Need higher resolution times for linpack benchmark

[Tim Prince]

N.M. Maclaren wrote:
> On Dec 13 2009, Delbert Franz wrote:
>> On Friday 11 December 2009, Steve Kargl wrote:
>>>
>>> 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.
>>
>> Yes, Steve, the benchmark may be archaic in the eyes of all the 
>> "youngsters", but it is not archaic because here is a report that just 
>> came out last month:
>> http://www.netlib.org/benchmark/performance.ps
> 
> It's archaic, and there is no way that I am a "youngster"! I agree with
> Steve that most uses of it are just plain crap.  However, I agree with
> you that it still has its uses.
> 
> When I was benchmarking supercomputers, I included it (with a variety of
> sizes, if I recall), as one of a suite of benchmarks, and ran it both in
> serial and with one copy on each processor.  Several vendors commented
> that it could be vastly improved, to which my response was that I was
> using it as a baseline test of the compiler's optimisation on typical
> antiquated code.  I also included similar tests of the BLAS and LAPACK,
> which I also ran in serial and parallel, to see what the tuned libraries
> delivered.  The differences were as you would expect :-)
> 
> 
> Regards,
> Nick Maclaren.
> 
> 
> 
If you're looking for archaic benchmarks which adjust themselves to the 
timer resolution, there's Livermore Fortran Kernels.  If using CPU_TIME 
or the archaic etime, it adjusts its repetitions up to 20 minutes, yet 
doesn't produce as useful a result as does a microsecond resolution 
timer with a 5 second run.  Supposing that you are testing the ability 
of the compiler to parallelize, you want an elapsed timer, such as 
omp_get_wtime(), not CPU_TIME or the archaic etime() or secnds().
As to 100x100 linpack, the original SpecFP forced several compiler 
vendors to include the KAP preprocessor/optimizer so as to defeat it by 
gaining cache locality.  That in turn forced introduction of new 
versions of SpecFP.
Speaking of archaic, my employer-sponsored OS installation doesn't know 
how to display postscript, after all these years of development.  I 
won't vote on whether the OS or .ps is archaic.