Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site cornell.UUCP
Path: utzoo!watmath!clyde!cbosgd!ihnp4!houxm!vax135!cornell!rej
From: rej@cornell.UUCP (Ralph Johnson)
Newsgroups: net.arch
Subject: Re: Cube designs vs. x,y,z bus
Message-ID: <491@cornell.UUCP>
Date: Thu, 28-Feb-85 22:08:52 EST
Article-I.D.: cornell.491
Posted: Thu Feb 28 22:08:52 1985
Date-Received: Sat, 2-Mar-85 02:45:57 EST
References: <48@pbear.UUCP> <268@oliveb.UUCP> <7306@watrose.UUCP> <5056@fortune.UUCP>
Organization: Cornell Univ. CS Dept.
Lines: 23
Summary: 

In article <5056@fortune.UUCP> wall@fortune.UUCP (Jim wall) writes:
>
>   Ah, surely you jest.  Given that each node on the psuedo cube has 
>its own associated memory, the vast majority of that processors time
>will be spent without touching the 'bus'.  And in most cases, the only
>times the bus is used is for infrequent data movement (lets say for 
>mmu misses) and for interprocessor communication.

I assume that you haven't built any large multiprocessors.  Forgive me
if I am wrong.  I haven't either, but I have talked to people who have,
and I read a lot of papers.  Most experts agree that lack of bandwidth
is death to a multiprocessor.  Go down the list of big multiprocessors
that have actually been built (Illiac 4, cm*, etc) and you will find that
the biggest problem with each has been that communication was too
expensive.  Most of the problems that require parallelism need a lot of
communication between processors.  Also, asynchronous buses with
multiple masters are slower than simple point to point communication
links.  A shared bus may work with a handful of processors, but not the
hundreds or thousands that are being discussed for cubes.

Ralph Johnson