Mon, 16 Jan 1995 12:05:18 -0800 (PST)
Well, I was thinking of a sort of radical modification to Mike's cell
ideas. I really don't know if the extra overhead could be overcome
(although I would imagine it could, with whatever degree of difficulty),
and therefore how possible it is, but I'll still throw it out....
The basic unit of "stuff" in the system is the cell. A cell can be
thought of as a "black box", with a number of unidirectional inputs and
outputs. A cell's output depends solely on its inputs. (In other words,
cells can't hold any data inside them. This might be an arguable point,
but its just the way I was thinking of it.)
The inputs and outputs can be plugged together using unidirectional
"connections". A connection's job is simply to take the output of one
cell and pass it to the input(s) of (an)other cell(s). In my model, the
connections would simply pass primitive types of cells around, but it
might be possible to pass raw integer data, etc.. Connections act like
electric wires: the signal keeps flowing until it is stopped at the other
end. This means connections do not amount the message sends.
Internally, cells are composed of a group of primitive cells
(support provided by the language), as well as any found useful in other
cell libraries. The combination of the input and the way in which these
internal cells are wired together determines the output.
All cells are processed in parallel, or pusdo-parallel for machines
lacking enough processors. =)
I'd imagine that a number of people are already griping about how
such a system could possibly go fast enough. I will admit that such a
system would not be as fast as raw assembler (and probably a linear LLL),
but that doesn't make it totally impossible. One point of consider is
that you needn't consult any look-up tables to pass a value to a
connection. If the two (or more) connected cells all share a common
variable, you could simply update that, and the connection would be
updated. No need to concern yourself to what object(s) it might be
To find the proper way to distribute cells over the availible
processors, AI or Genetic Algorithms could be used to "learn" or "evolve"
the best possible speed (or a close approximation thereof).
The other point people will be complaining about is how to represent
current-style programs in this new system, as it will probably take
people longer to think up a good distributed algorithm than a sequential
one. (We might be able to construct a Genetic Programming environment
designed to "unsequentialfy" existing programs, but that could be quite a
challenge.) To people who have the desire/need to run sequential code,
there would exist a number of ordering primitives. There could be a
library cell, for example, that would take a list of other cells to
interact with, and process them in order. Standard primitives could be
provided for semaphores, etc..
One of the nicest things here is that we eliminate the entire concept
of a process, turning the entire network of Tunes machines into one
giant, interconnected web. Having abolished this, we remain with a quite
good thing: persistant computation. There is no need to store program
counters or any other junk to achieve this, only the state of various cells.
"If it works, its obselete." -- Gerald Swapp
Chris Harris (firstname.lastname@example.org)
Check out my WWW page: http://weber.u.washington.edu/chharris
On Mon, 16 Jan 1995, Francois-Rene Rideau wrote:
> Well, what kind of abstraction do you propose for parallel computing ?
> Do you have any reference ?
> I do not. But I still think higher-order functions and continuations
> are a good concept for parallelism, from coarse-grained one down to mid-grain
> one. To join/fork would just be a construct to allow continuations to
> represent independent evaluation of different arguments of a same function.