Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site bonnie.UUCP
Path: utzoo!watmath!clyde!bonnie!jww
From: jww@bonnie.UUCP (Joel West)
Newsgroups: net.rumor,net.chess,net.arch
Subject: Re: Cosmic Cube and Transputers.
Message-ID: <455@bonnie.UUCP>
Date: Thu, 21-Mar-85 11:11:18 EST
Article-I.D.: bonnie.455
Posted: Thu Mar 21 11:11:18 1985
Date-Received: Fri, 22-Mar-85 02:48:24 EST
References: <825@ucbtopaz.CC.Berkeley.ARPA> <811@loral.UUCP>
Organization: CACI -- La Jolla, Calif.
Lines: 48
Xref: watmath net.rumor:705 net.chess:830 net.arch:1014

>    The Transputer has four bit serial I/O channels, so that you could build
>    at most a 4-D cube (each node in the cube network has connections to
>    four other processors).  The Cosmic Cube and the iNTEL iPSC are 6-D
>    cubes.

Actually the iPSC ranges from 5-D to 7-D.  The Caltech folks, true, have only
built a 6-d, but their whole design approach and philosophy has been to
support N-d.  I'm sure they will build a 7- or 8- within a year, and there are
those there who'd like a 10-D cube of 8086's.  

But, I agree, the current Transputer is impractical for cube design.  It
is claimed that future version will have more i/o channels.  If it did,
it might be worth using for a Cosmic Cube, as nwm@ucbtopaz first suggested.
The current T424 transputer claims 750 kbytes/sec vs 250 kb/s for the Cosmic
Cube, not a spectacular improvement--particularly compared to the 4 mbytes/sec
bandwidth of each channel on the DARPA-BBN "Butterfly".  

However, as Caltech has planned all along, the Cosmic Cube design will best be 
implemented in a single chip per node.  The size of the Cosmic and iPSC alone
are impractical in the long run for larger networks.  But with a chip-based
node, a 10-cube in a file cabinet becomes feasible.  Whether it's a
transputer or a "connection machine" or something from Caltech, I dunno.

>    Inmos has also been claiming that their Occam language is a great 
>    breakthrough in parallel processing languages.  I believe that an
>    examination of the Occam programmer's manual ("Occam Programming
>    Manual", INMOS Limited, Prentice-Hall International) is sufficient to
>    dispel INMOS's claims.
> 
> 		     Ian Kaplan
> 		     Loral Data Flow Group
> 	     USENET: {ucbvax,decvax,ihnp4}!sdcsvax!sdcc6!loral!ian

The 50? 80? page book is overpriced at $20.  And the claims made about how
everyone should use Occam for everything -- systems programming, scientific,
engineering, simulation, etc. -- are overrated.  The world doesn't need another
completely new language.  It has several thousand already, all but 20 of
which are not used by more than 100 people in the world.  Occam has some
nifty ideas, but those could be re-implemented around C (another portable
assembly language).  The rest of Occam is just someone's idea of idiosyncratic 
"innovation."
-- 
	Joel West				     (619) 457-9681
	CACI, Inc. - Federal 3344 N. Torrey Pines Ct La Jolla 92037
	jww@bonnie.UUCP (ihnp4!bonnie!jww)
	westjw@nosc.ARPA

   "The best is the enemy of the good" - A. Mullarney