Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!mips!winchester!mash
From: mash@mips.COM (John Mashey)
Newsgroups: comp.arch
Subject: Re: Historical architectural advances??
Message-ID: <42895@mips.mips.COM>
Date: 7 Nov 90 18:37:50 GMT
References: <8185@scolex.sco.COM> <1868@m1.cs.man.ac.uk> <8553@scolex.sco.COM> <1888@m1.cs.man.ac.uk>
Sender: news@mips.COM
Reply-To: mash@mips.COM (John Mashey)
Organization: MIPS Computer Systems, Inc.
Lines: 50

In article <1888@m1.cs.man.ac.uk> mshute@cs.man.ac.uk (Malcolm Shute) writes:

>What is the difference between a loosely coupled multicomputer system,
>and a tightly coupled multiprocessor computer?
>
>Granularity of processes for scheduling, and geography of the 'cabinet'
>size.  That is all (just about).

>Our LAN fits into a cabinet called the Department of Computer Science.
>How much smaller would it have to be before you would consider it to
>be a single multiprocesser computer?  Or, what other criterion would
>have to be met before it crossed the threshold?

Although I'd know people would argue with this, some, but I'd
suggest that there is a fairly clear dividing line between:
	a) Uniprocessors, and shared-memory multiprocessors
and
	b) Networks, or even loose-coupled multis in a box

Now, clearly, there is a lot of work going on to find ways to make
b) act more like a), and there has been a lot of progess, as in
network file systems, distributed RPCs, etc, and new algorithms
for using non-shared-memory systems.  However, we're not there yet,
and I doubt that some things EVER will get there.  (In some cases,
the only machine that helps you much is the fastest uni processor
you can build.)

Currently:
in practice,  I think the biggest distinction is USER EXPECTATION,
which sounds pretty weird, but I suggest is true.

If it is in one physical box, people expect:
	a) You can add another processor to the box, but the system
	administers like one system, more or less.
	*b) Performance on many job streams will be scaled up, if not
	by 100%, at least by some reasonable fraction, without
	restructuring of code, or doing anything in particular.
	In particular, people expect that load-balancing will occur
	almost invisibly, with relatively small granularity.
	c) With some work, some kinds of code can fairly easily
	exploit the random-access nature of shared memory,
	to make individual problems go faster (where problem could be
	a big scientific cruncher, or a DBMS, or...)

Most customers expect b), whether they should or not!
-- 
-john mashey	DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP: 	 mash@mips.com OR {ames,decwrl,prls,pyramid}!mips!mash 
DDD:  	408-524-7015, 524-8253 or (main number) 408-720-1700
USPS: 	MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086