Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: 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


   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.