Article View: net.arch
Article #2542Re: Help on Thinking Mach. Inc.
From: ian
Date: Thu, 22 May 1986 21:23
Date: Thu, 22 May 1986 21:23
79 lines
4690 bytes
4690 bytes
I would like to thank Eugene Brooks for his excellent article on the
Connection Machine (CM).
I attended a presentation by someone from Thinking Machines at the
Colorado School of Mines conference on super-computing. I found this
presentation fascinating, so I read Danny Hillis' book on the Connection
Machine when I got back. The book leaves a number of questions
unanswered:
* How is the CM programmed?
In the book there are some simple examples of Connection Machine Lisp,
but these just whet the appetite. There are supposed to be
applications like circuit simulators (10 K gates as I recall) that
have been run on the CM. How are these programmed? As Eugene
mentions, the CM is an SIMD machine that can be used to _simulate_ a
MIMD machine. I just don't have a good feel for how you program such
a system.
The Connection Machine Lisp manual is, evidently, unavailable to those
of us who do not have a million dollars to by a CM.
* In his book, Hillis mentions that network can develop "hot spots" of
network congestion. As I recall he references some articles that
specifically discuss hot spots in binary n-cubes. When a hot spot
develops messages can be routed along paths that are not as congested.
Imagine a message is traveling through the CM and it encounters a hot
spot. The message is rerouted. Just after it is rerouted, the
congestion clears and the next message to that destination goes
through the direct binary n-cube path. The two messages may now be
out of order, since the second message could arrive before the first.
If the CM does rerouting of the type described above, does it reorder
the messages at the destination? Since the CM is doing small grain
computation, what sort of overhead does this introduce?
* How does the CM handle processor failure?
The issue of fault tolerance is one that has been largely ignored in
parallel processor design (compare the number of articles on
interconnection networks with the number of articles on fault
tolerance in parallel processors). In parallel processors composed of
a hundred or so processing elements (PEs) implemented in VLSI technology
there is a relatively low probability of hardware failure. In a
system that is composed of thousands or millions of PEs hardware failure
approaches a certainty. How does the CM detect PE failure?
What happens to a program running on the CM when a PE fails?
How are messages rerouted to avoid the failed PE?
Thinking Machines has been, at least with me, very secretive about the
CM. Despite repeated requests they have not sent me any literature on
the system. I understand that some information may be proprietary and I
would not expect them to give this out. On the other hand the machine
is released so at least the Connection Machine Lisp manual should be
available. Thinking Machines should also be willing to answer some of
the questions above, since they are the sort of questions that
prospective customers might have.
I hope that the discussion on the net will produce some more information
on the Connection Machine. In the long run anyone who is serious about
their work on parallel processors will be interested in seeing the
entire computer science community move forward. This can not take place
without the exchange of information. I do not believe that this ideal
is incompatible with the desire for profit in the commercial world.
Once a machine is released for sale, information must be released to
sell it.
Ian Kaplan
Loral Dataflow Group
Loral Instrumentation
(619) 560-5888 x4812
USENET: {ucbvax,decvax,ihnp4}!sdcsvax!sdcc6!loral!ian
ARPA: sdcc6!loral!ian@UCSD
USPS: 8401 Aero Dr. San Diego, CA 92123
The opinions expressed in this article are entirely those of the author.
Technical Details
Message-ID:
<1142@loral.UUCP>Path:
arc1-ca.pugleaf.net!utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!decwrl!pyramid!gould9!ncr-sd!sdcsvax!sdcc6!loral!ianReferences:
<655@ur-helheim.UUCP> <1533@lll-crg.ARpA>Show Full Headers
Complete Article Headers
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: arc1-ca.pugleaf.net!utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!decwrl!pyramid!gould9!ncr-sd!sdcsvax!sdcc6!loral!ian From: ian@loral.UUCP Newsgroups: net.arch Subject: Re: Help on Thinking Mach. Inc. Message-ID: <1142@loral.UUCP> Date: Thu, 22-May-86 17:23:10 EDT Article-I.D.: loral.1142 Posted: Thu May 22 17:23:10 1986 Date-Received: Sun, 25-May-86 12:31:01 EDT References: <655@ur-helheim.UUCP> <1533@lll-crg.ARpA> Reply-To: ian@loral.UUCP (Ian Kaplan) Organization: Loral Instrumentation, San Diego Lines: 79