Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/5/84; site terak.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!hao!noao!terak!doug
From: doug@terak.UUCP (Doug Pardee)
Newsgroups: net.arch
Subject: Re: I don't believe your statements about multiprocessors
Message-ID: <544@terak.UUCP>
Date: Mon, 13-May-85 13:12:07 EDT
Article-I.D.: terak.544
Posted: Mon May 13 13:12:07 1985
Date-Received: Thu, 16-May-85 05:53:00 EDT
References: <7202@Glacier.ARPA>
Organization: Terak Corporation, Scottsdale, AZ, USA
Lines: 27

[I consider the word "always" as a personal challenge...]

> 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's not what everyone else is discussing, but there is *too* an
application where 10 10MIPS CPUs (MIMD) will beat 1 100MIPS CPU.  That's
where there are 10 totally independent jobs to be done.  For example,
multi-user operating systems.  A single CPU would have to deal with the
overhead of context switching.

Which leaves me kinda confused...

I gather from the preceding discussion that the Cray is a SIMD (vector)
machine, and does quite nicely on achieving high performance working on
a single job.  So why then would anyone want to bog it down with a
multi-user operating system?

Wouldn't it make more sense to build a multi-micro system to run the
operating system and for program development (one CPU for each user),
thereby freeing up the vector CPU to actually *run* jobs (one after
the other)?
-- 
Doug Pardee -- Terak Corp. -- !{ihnp4,seismo,decvax}!noao!terak!doug
               ^^^^^--- soon to be CalComp