Re: Designing a language for dataflow/parallelism

On 13 Jun 2005 17:57:19 -0400, tony@tonyRobinson.com wrote:


>There's clearly a tradeoff between expressiveness of the language and
>ability to optimise. Googling on "alias analysis" and "automatic
>scoping" gets me somewhere, for example the "why C can't be as fast as
>Fortran" debate, which is educational. However I'm really interested in
>the idea of a new language (or portable assembler, c-- style), so I'm
>looking for references, papers, projects on this sort of problem, more
>comparative analysis of different languages, or even just the right
>keywords to hit google with...


There aren't many languages *designed* for dataflow - I think because
there isn't consensus on what "dataflow" really means in terms of
nsoftware. There are languages which are more easily adaptable to the
basic ideas, however AFAIK, there has not been a lot of work done with
these languages on optimization for parallel execution - most are
single threaded models. [ You seem to be most interested in hardware
parallelism, but IMO the programming model is an important component
of parallelism. ]


When I first looked at dataflow back in the 80's the primary parallel
execution model was bag-resolution ... essentially an aggressive usage
of call-by-need. The basic idea was well outlined by Nick Carriero
and David Gelernter in their papers on Linda.


Dataflow seems to have been largely subsumed by constraint logic and
functional programming, although there are few parallel models
currently.


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.


George

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