Language bias

[Chris Harris]

    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 
directed to.
    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.

    Possible?

-Chris

"If it works, its obselete." -- Gerald Swapp
-------------------------------------------------------------
Chris Harris (chharris@u.washington.edu)
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.