🚀 go-pugleaf

In article <9079@batcomputer.tn.cornell.edu> kahn@tcgould.tn.cornell.edu 
writes:
>Throw away ALL your copies of the LINPACK 100x100 benchmark if you
>are interested in supercomputers.  The 300x300 is barely big enough 

In article <2203@brazos.Rice.edu> preston@titan.rice.edu (Preston Briggs) 
writes:
>Danny Sorenson mentioned recently that linpack is sort of intended
>to show how *bad* a computer can be.  The sizes are kept
>deliberately small so that the vector machines barely have a chance
>to get rolling.

In article <9089@batcomputer.tn.cornell.edu> kahn@batcomputer.tn.cornell.edu 
(Shahin Kahn) writes:
>It certainly is biased towards micros with limited memory and is
>absolutely irrelevant as a *supercomputer* application.  Yes, it
>can show how bad a supercomputer can be.

Well, I'll through in my $0.02 of disagreement with this thread.  It
has been my experience that the poor performance of the LINPACK
100x100 test on supercomputers is *entirely typical* of what users
actually run on the things. There a plenty of applications burning up
Cray, Cyber 205, and ETA-10 cycles which have average vector lengths
*shorter* than the average of 66 elements for the LINPACK test, and
which are furthermore loaded down with scalar code.

The 100x100 test case is not representative of *everyone's* jobs, but
it is not an unreasonable "average" case, either.  I think it is much
more representative of what most users will see than the 1000x1000
case, for example.  The 1000x1000 case is a very good indicator of
what the *best* performance will be with *careful optimization* on
codes that are essentially 100% vectorizable.  Most of the
supercomputer workload does not fall into that category....
--
John D. McCalpin - mccalpin@masig1.ocean.fsu.edu
		   mccalpin@scri1.scri.fsu.edu
		   mccalpin@delocn.udel.edu