Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!think!danny
From: danny@think.COM (Danny Hillis)
Newsgroups: comp.arch
Subject: Re: Connection Machine Argument
Message-ID: <246@think.COM>
Date: Thu, 4-Dec-86 20:58:14 EST
Article-I.D.: think.246
Posted: Thu Dec  4 20:58:14 1986
Date-Received: Fri, 5-Dec-86 05:22:24 EST
References: <745@husc6.UUCP>
Distribution: na
Organization: Thinking Machines Corp., Cambridge, MA
Lines: 24
Summary: Answer to Reiter arguments about the Connection Machine


	Your argument mixes two ideas. If by "Connection Machine" you
mean the current 64K-processor implementation (the CM1) then it is not
implemented on a wafer, so the arguments do not apply. Those wires are
not a large part of the overall cost of a CM1. If on the other hand you
mean the Connection Machine architecture, in the sense of a family of
software compatible machines, then there is no reason to constrain the
implementation to either single bit processors or are to any particular
interconnection topology. Connection Machine programs do not depend on
those details.
	The main point of the Connection Machine architecture is to
provide a level of abstraction at which these things don't matter.
Things like the optimal interconnection topology and processor size are
dependent on time-varying details like the cost of connectors, the
feasibilty of wafer-scale intergration, and the size of the machine.
The programmer would presumably like to write code that keeps running
faster as these things improve, without having to rethink everything each
time someone invents a new interconnection topology. That's why the
Connection Machine has a message router.
	I certainly agree with your arguments that hypercubes are not
likely to be the best interconnection topology for wafer-scale machines
and that we can use larger processors as it becomes easier to make them,
but I think these are reasons why the Connection Machine architecture
makes sense.			-danny