Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!cr83.staffordshire-polytechnic.ac.uk!CDRIW
From: CDRIW@cr83.staffordshire-polytechnic.ac.uk
Newsgroups: comp.sys.transputer
Subject: Grainyness
Message-ID: <00002D20_002420B8.0092C1391F8A26C0$1_6@UK.AC.STAFPOL.CR83>
Date: 10 Oct 89 22:49:30 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 29

Grain for thought:

Performance with programmability is the target.  Surely the point is to
keep the memory as busy as possible?  Cycles-per-instruction is not the
issue, but accesses-per-memory-location.  Microprocessors in general
are too big:  A 10 mip processor with 10 Meg of RAM accesses each
location only once per second.  What a waste of RAM!

The `grain-y-ness' of occam is great, with its 3 primative processes,
hierarchical process structure and lack of shared memory.  When applied
to transputers however, the niceness begins to break down.
Distributing a program on transputers imposes a flat process structure,
with a limit of 4 channels per process.  Processes with internal
parallelism (i.e. communication) run time-sliced.  What is required is
transputers with internal transputers!

How about a (size 1) TRAM with 4 T2s arranged in a tetrahedral
structure, although RAM would be a big problem here.  Even more
interesting would be 4 (say) transputers on the same die.  In this case
the intra-die link engines need not be serial but 8- (or why not 32-)
bit parallel -- this would really get the data flowing.

We need systems with *much* higher processor-communication / RAM.  This
may require smaller processors with better communication (looks very
neural-nettish, eh?)

Iestyn Walters.                     "Representation is the essence
                                     of programming" -- Where does that
                                                        leave occam?