Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 8/28/84; site lll-crg.ARPA
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!ihnp4!houxm!whuxl!whuxlm!akgua!sdcsvax!dcdwest!ittvax!decvax!genrad!panda!talcott!harvard!seismo!umcp-cs!gymble!lll-crg!brooks
From: brooks@lll-crg.ARPA (Eugene D. Brooks III)
Newsgroups: net.arch
Subject: Hypercubes
Message-ID: <418@lll-crg.ARPA>
Date: Wed, 27-Feb-85 00:27:08 EST
Article-I.D.: lll-crg.418
Posted: Wed Feb 27 00:27:08 1985
Date-Received: Sun, 3-Mar-85 02:54:47 EST
Distribution: net
Organization: Lawrence Livermore Labs, CRG group
Lines: 30

WARNING: Serious flames here!

It really upsets me that an individual would claim that a bus architecture
is better than a Hypercube when the first thing he does in his argument is
give the bus a 300 megabyte a second bandwidth and give the hypercube the
equivalent of 9600 baud serial lines to communicate with.  If you need that
kind of edge to prove your point you are in DEEP TROUBLE.

In the Caltech project the communication speed of each channel was on par
with the floating point speed as it should be in numerical applications work.
If the floating point speed of a node is 10MFLOPS, as it is for current high
cost/performance ratio hardware these days, the communication channels should
support a transfer rate to match.

For those who wish compare the Hypercube to the x, xy, xyz, (or xyxt....) bus
Just what do you think a hypercube is?  Its a xyzt... bus with the number
optimized.  Just two cpus connect to each bus (the word bus is used loosely
here)  What is better?  Nothing!

For those who want to complain that a Cube of order=20 would require each
processor to manage 20 messages on average being a bad thing there is of
course a better way to build the hardware if this is a problem.  The problems
to which the Cube has been put to in the past used only communication
with neighboring processors and rather straightforward maps of the problem
onto the machine.  If your problems are of a sort that require random addressed
message fordwarding then you need to consider the alternate (and more expensive)
hardware design.  There is the old adage "You get what you pay for." In fact
you probably should be considering a shared memory machine.

	Perhaps even a Hypercube!