Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site mtu.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!harvard!talcott!panda!genrad!decvax!decwrl!Glacier!mtu!pop
From: pop@mtu.UUCP (Dave Poplawski)
Newsgroups: net.arch
Subject: Re: I don't believe your statements about multiprocessors
Message-ID: <184@mtu.UUCP>
Date: Thu, 9-May-85 11:57:58 EDT
Article-I.D.: mtu.184
Posted: Thu May  9 11:57:58 1985
Date-Received: Sun, 12-May-85 01:23:34 EDT
References: <7202@Glacier.ARPA>
Distribution: net
Organization: Michigan Tech, Houghton, MI
Lines: 36

> I have never seen a single particle of evidence, not one number, that says
> that a tightly-coupled (e.g. shared-memory) multiprocessor is in any way
> better than a uniprocessor of the equivalent aggregate speed. If you know
> how to build a 100-MIP uniprocessor CPU, or 10 10-MIP processors for the
> same instruction set, or 100 1-MIP processors, then it is always much better
> to have the uniprocessor. It might be cheaper to build the multiprocessor,
> but the uniprocessor is a better computer.

I don't think you will get any arguments about this - anybody would  rather
have  a  10,000  MFLOPS  uniprocessor  than  a 10,000 MFLOPS multiprocessor
(shared memory, hypercube, mesh or whatever) - I would if  the  price  were
comparable  or  even if the uniprocessor were more expensive.  Avoiding the
reprogramming effort to express the parallelism in sequential  programs  in
sequential  languages  would probably make up the difference in cost.  Even
for new programs, most of us still find it easier  to  write  a  sequential
program  than  a  parallel  (especially massively parallel) program, and in
many cases there isn't that much parallelism in the problem  in  the  first
place.

> Of course it is not always possible to build a uniprocessor as fast as one
> would like, so multiprocessors and vector machines have always been at the
> leading edge of the speed wars, but this is not because they are better
> computers but because people know how to build them.

Exactly -  you  answered  your  own  question!   As  long  as  the  fastest
uniprocessor  available  is  a  couple  of  orders of magnitude slower than
available multiprocessors, and there are people who want  (need)  to  solve
problems  that are adaptable to the multiprocessor, then the multiprocessor
will be better (for those people and  those  applications).   There  is  no
religion  here,  just  technology.  As soon as you can build a uniprocessor
that is as fast as any multiprocessor, the multiprocessors will go away.
-- 
Dave Poplawski
Michigan Technological University
uucp: {lanl, ihnp4, glacier}!mtu!pop
arpa/csnet:  pop%mtu@csnet-relay