dave@ur-helheim.UUCP (Raver Dave) (05/20/86)
Can anyone present a version of what exactly Thinking Machines
computer is? Articles from WSJ etc have been vague at best.
I'm pretty sure these guys are on the net. Any help, pointers
to articles etc would be useful. Reply via mail or if of general
interest, here.
dave
--
"The Faster I Go the Behinder I Get"
--Lewis Carroll
Dave Carlson
{allegra,seismo,decvax}!rochester!ur-valhalla!davebrooks@lll-crg.ARpA (Eugene D. Brooks III) (05/21/86)
In article <655@ur-helheim.UUCP> dave@ur-helheim.UUCP (Raver Dave) writes: >Can anyone present a version of what exactly Thinking Machines >computer is? Articles from WSJ etc have been vague at best. Lets try prodding them into discussion: I will try to provide a meager description, collected from a paper about the Connection Machine I recently read. There may be inaccuracies, due to lack of information in the paper, but I think that my description in general is reasonably close. The machine is a SIMD computer in which each cpu is bit serial and communicates with others by passing messages. Every cpu executes the same "nanoinstruction" which is farmed out by a single instruction decoder than takes "macroinstructions" from a host. Each cpu in the CM executes the same instruction, with at least the one proviso (there may be more) that it may sit the instruction out based on the value of an internal flag. I think that it is reasonable to consider the DAP a close ancestor of the Connection Machine. The Thinking Machines people may not agree, and may strongly disagree, and I do not speak for them. In the sprit of stirring up trouble I will compare the two machines. Like the DAP, the CM is a SIMD message passing machine where each cpu is bit serial, making sqrt as fast as floating add, and the collective memory of the CM "cpus" is visible to a "host" as memory. Each bit serial cpu in the CM, like the DAP, does not share memory with the other cpus. They communicate by passing messages. The basic ammount of memory available on each cpu is a few K bits or so. Roughly the same ammount of memory, per cpu, was available on the DAP. The number of cpus in the CM, 2^16, is quite a bit larger than that of the DAP. The C.M. is implemented with much more recent technology and one expects N to increase due to VLSI advances. Due to the VLSI implementation each cpu has quite a bit more functionality than that of the DAP. There are two reasons why the C.M. is more interesting than the DAP. The software for the C.M. is of course much more advanced. The significant hardware difference is the communication topology used in the C.M. Instead of the 2 D mesh without message routing hardware, which was used in the DAP, the CM uses the direct 2-ary n-cube topology used in the Caltech Hypercube machine. The C.M. also has hardware support for message routing from any cpu to any other which is critical to applications which do not "fit" on the network. Because of the Hypercube network topology, which has many interesting networks imbedded within it, the C.M. will be able to run many diverse algorithms efficiently, using nearest "hypercube" neighbor communication. Because of its routing hardware, algorithms that do not map well onto the Hypercube, and might otherwise suffer in performance, will also do well on the machine. The bottom line for performance on the "hard" parallel algorithms is high peformance communcation between processors, which I perfer to have in the form of SHARED MEMORY. The fundamental shortcoming of the CM is that it is a SIMD machine. Each cpu executes the same instruction, or sits out the instruction cycle, which is a very restrictive programming model. The DAP certainly did some things well, and given the fact that the CM is much more flexible and has message routing hardware for long distance message passing, it should do well on a much larger class of parallel applications. It remains to be seen whether the SIMD message passing system is sufficiently general to become a general purpose parallel computer. It also remains to be seen if the CM will be a success in the commercial market, the DAP was not. Eugene
ian@loral.UUCP (05/23/86)
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.