Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!uakari.primate.wisc.edu!brutus.cs.uiuc.edu!apple!sun-barr!newstop!texsun!convex!eugene!swarren
From: swarren@eugene.uucp (Steve Warren)
Newsgroups: comp.arch
Subject: Re: linpack
Message-ID: <2242@convex.UUCP>
Date: 20 Oct 89 15:59:30 GMT
References: <35825@lll-winken.LLNL.GOV> <127@csinc.UUCP> <9079@batcomputer.tn.cornell.edu> <2203@brazos.Rice.edu>
Sender: news@convex.UUCP
Reply-To: swarren@eugene.UUCP (Steve Warren)
Organization: Convex Computer Corporation, Richardson, Tx.
Lines: 26

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.
>
>So, big if you're optimistic; small otherwise.
>
>Preston Briggs


That is sort of like testing a dump-truck on a slalom course.  A vector
machine should have balanced performance on scalar code, but you are
buying vector performance primarily.

So, big if you want to see if it can do what you are paying for, small
if you want to see if it can do anything else.

--Steve
-------------------------------------------------------------------------
	  {uunet,sun}!convex!swarren; swarren@convex.COM