Thread View: comp.sys.transputer
1 messages
1 total messages
Started by CDRIW
Tue, 10 Oct 1989 22:49
Grainyness
Author: CDRIW
Date: Tue, 10 Oct 1989 22:49
Date: Tue, 10 Oct 1989 22:49
29 lines
1943 bytes
1943 bytes
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?
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads