Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site cornell.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!vax135!cornell!kevin
From: kevin@cornell.UUCP (Kevin Karplus)
Newsgroups: net.arch
Subject: Transputer and occam
Message-ID: <440@cornell.UUCP>
Date: Fri, 22-Mar-85 10:58:41 EST
Article-I.D.: cornell.440
Posted: Fri Mar 22 10:58:41 1985
Date-Received: Sat, 23-Mar-85 03:13:00 EST
References: <825@ucbtopaz.CC.Berkeley.ARPA> <811@loral.UUCP> <455@bonnie.UUCP>
Reply-To: kevin@gvax.UUCP (Kevin Karplus)
Organization: Cornell Univ. CS Dept.
Lines: 39
Summary: 

Occam is not a completely idiosyncratic language.  It is an
implementation of CSP (Communicating Sequential Processes), which has
been used by theorists for years as a simple, concise notation for
discussing concurrent programs.

Occam is clearly not a programming language to end all programming
languages, but it provides a simple way to talk about communication
between processes (somthing NOT provided by C, PASCAL, FORTRAN, PL/I,
...).

I've not programmed in Occam, have been considering it seriously.
Occam is available cheap to universities (call inMOS for details), and
runs on VAXes as well as Transputers.

The transputer chip looks ideal for systolic array designs.  It lacks
enough channels for a hypercube, but as other people have pointed out,
it isn't clear that a small processor can handle lots of channels.
The transputer does not look very good as a part of a "pseudo-node" of
a hypercube (each chip has one edge of the cube, and shares a bus with
the other processors at the same node), since it does not have a
shared-bus communication port.

I'm a little dubious about the value of hypercubes, as most big
programs have a 5% to 20% purely serial component.  Even doing the
parallel part in zero time is only a 5 to 20 times speedup.  Any
machine that hopes for bigger speedups must have at least one extermely
fast serial processor.  (Note: this only applies to general-purpose
machines.  Obviously, certain problems can have the serial part reduced
to a tiny fraction.)

I like the idea of including a disk drive at every node of a cube.  It
is incredibly expensive, but many disk drives with a processor for each
is the only way to get fast databases.  I'm not convinced a cube is the
right architecture, though.  There are networks with fewer links that
are amost as fast, and much cheaper to build.

				Kevin Karplus

[Standard disclaimers]