Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site ho95b.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!ihnp4!houxm!ho95b!wcs
From: wcs@ho95b.UUCP (Bill Stewart)
Newsgroups: net.arch
Subject: Re: I don't believe your statements about multiprocessors
Message-ID: <411@ho95b.UUCP>
Date: Tue, 14-May-85 14:37:01 EDT
Article-I.D.: ho95b.411
Posted: Tue May 14 14:37:01 1985
Date-Received: Wed, 15-May-85 01:19:50 EDT
References: <7202@Glacier.ARPA> <761@mako.UUCP>
Organization: AT&T Bell Labs, Holmdel NJ
Lines: 25

Multiprocessing has a number of advantages over uniprocessing, which
in many circumstances outweigh the disadvantages.  The primary
reason for multiprocessor machines is of course technology - it's a
lot easier to combine 100 10-MFLOP processors than to build a 1-GFLOP
processor  (and if you build one, you can combine 100 of THEM.)

If the processing you really want to do is true uniprocessing, then
probably the fast uniprocessor will win.  But most computing is
inherently multiprocessing - either there are multiple users, or
the problem has a reasonable degree of parallel structure that can
better be exploited on a multiprocessor (e.g. finite element
calculations, network modelling, etc.)  On the multiprocessor, each
processor can potentially take its one job and grind away; the
uniprocessor wastes a lot of overhead doing process switches,
swapping and paging.  On the other hand, the multiprocessor wastes
power when there are idle processors, whereas the uniprocessor goes
faster if it has fewer jobs to do.  The value of either approach
really depends on the application environment and the tradeoffs you
have to make; neither can be ruled out.

			Bill Stewart
-- 
			Bill Stewart	1-201-949-0705
			AT&T Bell Labs, Room 4K-435, Holmdel NJ
			{ihnp4,allegra,cbosgd,vax135}!ho95c!wcs