Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site cmcl2.UUCP
Path: utzoo!linus!philabs!cmcl2!gottlieb
From: gottlieb@cmcl2.UUCP (Allan Gottlieb)
Newsgroups: net.arch
Subject: Re: Transputer and occam
Message-ID: <828@cmcl2.UUCP>
Date: Wed, 3-Apr-85 21:34:16 EST
Article-I.D.: cmcl2.828
Posted: Wed Apr  3 21:34:16 1985
Date-Received: Sun, 7-Apr-85 06:21:07 EST
References: <825@ucbtopaz.CC.Berkeley.ARPA> <811@loral.UUCP> <5393@utzoo.UUCP>
Reply-To: gottlieb@cmcl2.UUCP (Allan Gottlieb)
Organization: New York University
Lines: 26
Summary: 

>> >I'm a little dubious about the value of hypercubes, as most big
>> >programs have a 5% to 20% purely serial component.
>> >(Note: this only applies to general-purpose
>> >machines.  Obviously, certain problems can have the serial part reduced
>> >to a tiny fraction.)
>> 
>> Have you any data to support this claim?
>
>There is one very large piece of supporting data:  CDC's incredibly
>expensive failure, the Star-100 supercomputer, which ran vectors very
>quickly and scalars very slowly.  

Vectorizable does not equal parallelizable.  We have good
evidence that the percentage of inheriently serial code goes down with
problem size for a number of important applications.  There 
still remains the question of whether sufficient high cache hit ratios
will occur to keep the processor-memory network from being saturated.
Also I/O is a serious question and there are others.  But I repeat,
our simulation data seem to clearly show that there is not this
absolute limit on speedup caused by a fixed percentage of inheriently
serial code (or at least any such limit is VERY high thousand-fold
speedup is definitely possible).
-- 
Allan Gottlieb
GOTTLIEB@NYU
{floyd,ihnp4}!cmcl2!gottlieb   <---the character before the 2 is an el