Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!mcnc!rti!dg_rtp!wood
From: wood@dg_rtp.UUCP (Tom Wood)
Newsgroups: comp.arch
Subject: Re: chewing up mips with graphics
Message-ID: <2120@dg_rtp.UUCP>
Date: Tue, 16-Jun-87 08:13:22 EDT
Article-I.D.: dg_rtp.2120
Posted: Tue Jun 16 08:13:22 1987
Date-Received: Sun, 21-Jun-87 06:35:36 EDT
References: <8270@amdahl.amdahl.com> <359@rocky2.UUCP> <6240@steinmetz.steinmetz.UUCP> <6328@beta.UUCP>
Reply-To: wood@dg_rtp.UUCP (Tom Wood)
Organization: Data General, RTP North Carolina
Lines: 24

The recent discussion on how to feed your poor starving CPU leaves me
a bit in the dark.  What architectural features help in dealing with
these various applications (graphics, simulation, object oriented AI,
CAD)?

For sake of discussion, I propose we normalize the O/S to Unix.  Are
these applications implemented using multiple processes?  If so, a
multiprocessor could be of help.  If not, it seems you'ld have to try
to build a "Cray": one fast monolithic processor.

Personally, I believe the 90% solution to obtaining parallelism is to
take advantage of multiple independent computations.  (It's much easier
to make 100 compiles go 100 times faster by using 100 machines than it
is to make 1 machine go 100 times faster on each compile.)

So how many fast CPUs can these applications benefit from?  My guess is
that most would have a hard time using more than 1, and that some may
be able to use 2 or so.  What would you do (short of rewriting the
application) if you were given a machine with 10-15 fast CPUs to put
on your desk?
-- 
			Tom Wood             (919) 248-6067
			Data General, Research Triangle Park, NC
			{the known world}!mcnc!rti-sel!dg_rtp!wood