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