Re: Designing a language for dataflow/parallelism

On 19/06/2005, at 1:20 PM, George Neuner wrote:
> [..]
> For implementation ideas relevant to dataflow I guess I would look at
> things like Linda, Occam, MultiLisp and Mul-T, OPS-5, Prolog, Haskell
> and Erlang. None of these are dataflow languages per se, but they are
> easily adaptable to the model and you might get some clues from
> looking at them.


Just to add two pointers to George's list:


- There is a body of work building on Wadge's Lucid:


http://i.csc.uvic.ca/home/hei/hei.ise%3Ctop:lucid%3E


including Lustre and Lucid Synchrone. My understanding is that these
languages are intended to be compiled into sequential code, i.e.
existing implementations resolve all concurrency at compile-time. If
you simplify these models by throwing out the clock calculus, you end
up with Claessan / Sheeran / Singh's Lava hardware description
language, which I think is a good place to start.


- There was a lot of work done by people at MIT in the 80s on
dataflow hardware and what language support should look like. Google
for Arvind or "MIT dataflow". Here the goal is to recover the
parallelism implicit in a program and exploit locality to avoid the
von Neumann bottleneck. I half-remember hearing their ideas made it
into one of the Alpha chips (but someone correct me if they know the
story, please).


You may also care to look at what Apple's doing with CoreAudio,
CoreVideo and Core<somethingelse>. In brief: all these are pipelined
(== dataflow-oriented) rendering libraries that use some tricks to
speed things up, such as demand-driven computation (aka lazy
evaluation).


cheers
peter

Return to the comp.compilers page.
Search the comp.compilers archives again.