Designing a language for dataflow/parallelism

George,


On 21 Jun 2005 13:51:51 -0400, George Neuner <gneuner2@comcast.net>
wrote:


> Lucid looks quite interesting, but it seems to be based on a systolic
> processing model - the clocking, though implicit, is visible to the
> programmer and if you remove it, everything falls apart.


I'm not too familiar with Lucid, but all the recent synchronous
dataflow languages have explicit clocks. The idea is to provide nice
support for programming reactive systems, which need to be
finite-state in order to keep reacting. The clocks ensure that buffers
have fixed static lengths and that there is no deadlock, so one can
statically schedule things and make it all quite efficient.


> As I understood it (a long time ago, mind you) the dataflow model was
> based on asynchronous logic with registers, conceived originally as a
> method to aggressively exploit inherent parallelism in programs and to
> transparently scale programs to the expected [massively] parallel
> hardware. It was a low level, run time model meant to be suitable as
> a common base for language implementation.


This was my second reference, to the work done at MIT. I am (even)
less familiar with it.


Just for the record (or Google), some people at Berkeley talk about
"dataflow process networks" which are perhaps closer to what you have
in mind.


One small nit:


> Though I'm not aware of any modern language whose run time model
> embodies all of the above, many employ significant parts of it. The
> FPLs as a group are the closest, most being based on graph
> traversal/reduction and templated generics and many supporting pattern
> matched execution - although they reverse the control, driving
> execution from the graph rather than from pattern matching.


The thing that drives computation in Haskell (the purportedly
canonical lazy FP) is the need to know what something evaluates to,
and this need arises from the desire to know which way to branch in a
"case" (pattern matching) expression... so you could say it is driven
by pattern matching. [*] I might be misunderstanding you, though.


I don't think strict functional languages need to go to the trouble of
using graph reduction, but perhaps someone else should comment on
that.


cheers,
Peter.


[*] This is not explicitly in the standard as far as I know, but is
implied in various places.

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