Simon Peyton Jones

The MIT data flow machine was all based on that idea.

Throw the whole graph into the token store and just run all the nodes that are runnable.

But that's incredibly fine-grained.

You've got to imagine this big tree of a million nodes, and your processor is sort of wandering around over it doing little things in parallel.

There's a lot of memory traffic going on there, and if these little threads are operating on the same bit of tree, then there's synchronization costs.

So very, very fine-grained parallel computation like this turns out to be impractical.

Or not impractical.

You could do it, but it's very slow.

So the Dataflow people, their history, if you look at the history of the MIT Dataflow project, they started with micro-parallelism.

Every individual instruction was a separate parallel computation that might take place and the token store would match it up.

And then they built more and more compiler technology that grouped these things together into larger units.

So they expanded from micro-threads of single instruction threads into 10 instruction threads or 100 instruction threads.

Right.

But even that never really caught on.

So you're right, though, that if I say in a Haskell program, E1 plus E2,

then I can do E1 and E2 in parallel.

And GHC does support you in doing that.

But nowadays, rather than expecting the compiler to do that automatically for every subexpression, you can spark a computation.

You say E1 par E2, and that says do E1 and E2 in parallel.

There's a project at Carnegie Mellon for a strict language called ML.