Skip to content

Latest commit

 

History

History
99 lines (64 loc) · 6.29 KB

cel.md

File metadata and controls

99 lines (64 loc) · 6.29 KB
Raw
layout title
default
Cell

i/o cells paradigm

Following sentences define a the programming paradigm with the name i/o cells1.

Each cell is ..

  • .. is independent
  • .. is simple and stupid
  • .. does not know about outside
  • .. calculates the output(s) from the input(s)
  • .. has no side effects
  • .. has 0 to N inputs
  • .. has 0 to 1 outputs (or M outputs)
  • .. has 0 to N incoming connections from other cells
  • .. has 0 to M output connections to other cells

Each cell can ..

  • .. be a group of other cells
  • .. have its own memory, but can forget

Note: the output could be the input of a cell but not at the same time, only t+1. So the output at time t can be the input of a cell at t+1. Cells lives in time.

There are a huge amount of cells that are connected together. Connections can be programmed. I/O cells are like nerve cells2 who produce an output signal from incoming signals from other cells.

i/o cells and AI

But this i/o cell paradigm has nothing to do with AI or brain stuff. I agree with Joseph Weizenbaum who said in the movie Plug&Pray that it is a big mistake that people believe everything can be computed. But we can learn from the way our brain is build. Like we learned from birds and build areoplanes.

Basically a computer is an I/O device. With inputs like keyboard and mouse and ouputs like screen or speaker.

Simulate

Currently you can simulate i/o cells paradigm via channels and green threads. Because this paradigm need a hardware like a modern dataflow architecture2. This hardware would be similar to our humane brain hardware, where each neuron is permanent calc output from input signals.

So CSP and GO3 is a good start to play and simulate the paradigm. Following example show to add cells that calculate c = a+b. The result c is then piped into the channel and the next add cell takes out the result c and take it for b.

Example

A simple cell adds to inputs (a, b) and produce an output c. The cell is running in a loop parallel to other cells. It produces output from input. If input a is there and input b is there it can generate output c. Inputs can come at any time. If both inputs are available the output will be produced.


        ┌───────┐
   b ──>o ┌─<─┐ │       connect       ┌───────┐
        │  add  o──> c --------- b ──>o ┌─<─┐ │
   a ──>o └─>─┘ │       channel       │  add  o──> c
        └───────┘                a ──>o └─>─┘ │
                                      └───────┘

When data is flowing through channel4 a and data is flowing through channel b then also computed data is flowing2 out of channel c.

Dataflow programming

See Wiki Dataflow_programming

State

One of the key concepts in computer programming is the idea of state, essentially a snapshot of various conditions in the system. Most programming languages require a considerable amount of state information, which is generally hidden from the programmer. Often, the computer itself has no idea which piece of information encodes the enduring state. This is a serious problem, as the state information needs to be shared across multiple processors in parallel processing machines. Most languages force the programmer to add extra code to indicate which data and parts of the code are important to the state. This code tends to be both expensive in terms of performance, as well as difficult to read or debug. Explicit parallelism is one of the main reasons for the poor performance of Enterprise Java Beans when building data-intensive, non-OLTP applications.[citation needed]

Where a sequential program can be imagined as a single worker moving between tasks (operations), a dataflow program is more like a series of workers on an assembly line, each doing a specific task whenever materials are available. Since the operations are only concerned with the availability of data inputs, they have no hidden state to track, and are all "ready" at the same time.

Representation

Dataflow programs are represented in different ways. A traditional program is usually represented as a series of text instructions, which is reasonable for describing a serial system which pipes data between small, single-purpose tools that receive, process, and return. Dataflow programs start with an input, perhaps the command line parameters, and illustrate how that data is used and modified. The flow of data is explicit, often visually illustrated as a line or pipe.

In terms of encoding, a dataflow program might be implemented as a hash table, with uniquely identified inputs as the keys, used to look up pointers to the instructions. When any operation completes, the program scans down the list of operations until it finds the first operation where all inputs are currently valid, and runs it. When that operation finishes, it will typically output data, thereby making another operation become valid.

For parallel operation, only the list needs to be shared; it is the state of the entire program. Thus the task of maintaining state is removed from the programmer and given to the language's runtime. On machines with a single processor core where an implementation designed for parallel operation would simply introduce overhead, this overhead can be removed completely by using a different runtime.

Footnotes

  1. Input/output automaton ↩

  2. Dataflow Architecture ↩ ↩2 ↩3

  3. Bell Labs and CSP Threads ↩

  4. CSP ↩