Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!super!rminnich
From: rminnich@super.ORG (Ronald G Minnich)
Newsgroups: comp.arch
Subject: Re: Scalability?
Message-ID: <25185@metropolis.super.ORG>
Date: 2 May 90 13:52:45 GMT
References: <2075@naucse.UUCP> <6897@odin.corp.sgi.com> <49622@lanl.gov> <1990May1.154558.24009@cs.rochester.edu>
Sender: news@super.ORG
Reply-To: rminnich@super.org (Ronald G Minnich)
Organization: Supercomputing Research Center, Bowie, Md.
Lines: 21

In article <1990May1.154558.24009@cs.rochester.edu> crowl@cs.rochester.edu (Lawrence Crowl) writes:
>A common trap is measuring parallel speedup is to use a "loaded" CPU.  For
>instance, the single processor might have been serving interrupts, clock
>icons, etc.  The result is that the performance for the single processor case
>is artificially low.  After taking care, the numbers usually turn out slightly
>less than linear.  
This is true, but it is also true that you can get superlinear speedup 
if the problem was so big that the single-processor machine just sat and
thrashed its guts out. I have seen this with my Mether DSM, where 
splitting the problem up decreased the working set enough that a 
two-or-four processor system could actually run, where a one-processor
version would sit and exercise disk arms. Kai Li also found a similar 
situation with Ivy. 
   To put it another way, if the runtime is infinity for one processor, 
and you can just about run it on two, then you get superlinear speedup :-)
ron
P.S. BTW, if anyone on this list is going to ICDCS, and you are doing 
     DSM implementations too, I would enjoy meeting you at ICDCS! 
     Send mail .... rminnich@super.org
-- 
rminnich@super.org