Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!batcomputer!kahn
From: kahn@batcomputer.tn.cornell.edu (Shahin Kahn)
Newsgroups: comp.arch
Subject: Re: linpack
Message-ID: <9089@batcomputer.tn.cornell.edu>
Date: 19 Oct 89 05:13:31 GMT
References: <35825@lll-winken.LLNL.GOV> <127@csinc.UUCP> <9079@batcomputer.tn.cornell.edu> <2203@brazos.Rice.edu>
Organization: Theory Center, Cornell U., Ithaca NY
Lines: 30

In article <2203@brazos.Rice.edu> preston@titan.rice.edu (Preston Briggs) writes:
>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
>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.

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.  I dont believe, however,
that it was *intended* to do that.  My theory is that the size was
set smallish because a 100x100 matrix wasnt considered so small
back then, and the algorithm is suboptimal because that's what
level-1 BLAS and the LINPACK library did back then.  There were
people who were implementing equivalents of level-2 BLAS and even
the emerging LAPACK kernels, but those didnt get blessed by the
Linpack benchmark until the 300x300 and finally the 1000x1000 were
included.

DONT compare supercomputers with the 100x100 linpack.
If you must use linpack 100x100, use linpack 300x300!  And then
submit 37 copies of the program at once and see which machine 
does 37 copies the fastest, and which one allows you to use the
keyboard while its running them!!

Read JackWorlton's paper in SupercomputerReveiw of Dec.88 or Jan.89,
and then if you still want to use linpack, at least you'll do it
with better knowledge.