Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!ukma!gatech!hubcap!bjornl
From: bjornl@tds.kth.se (Bj|rn Lisper)
Newsgroups: comp.parallel
Subject: Re: Hmm!  ( CM info / also req. dataflow info )
Message-ID: <3507@hubcap.UUCP>
Date: 11 Nov 88 12:56:07 GMT
Sender: fpst@hubcap.UUCP
Lines: 39
Approved: parallel@hubcap.clemson.edu


Regarding this discussion about routing in the Connection Machine....it
strikes me that there might be some discrepancies between the CM as
described in Hillis' book and the CM as it came out in reality. Especially
the CM-2 may be somewhat different, since when TMC designed that machine
they had learned from the experience of the CM-1. The NEWS routing, for
instance. If I recall this correctly (I hope I'm not on thin ice here), the
NEWS routing in the CM-2 is reconfigurable so it can be a multidimensional
grid. The original NEWS grid was two-dimensional only (with possible
wraparound, to make a torus). (This, if correct, supports my belief that the
NEWS routing is embedded within the hypercube.)

Christopher Hassell further writes:
>Now! What I would like to find out about is any dataflow architectures
>out there and their success.  Yes, I've read about Lucid and was interested
>but I would prefer to find out about any that aren't so queue dependent.

There's been a remarkable silence around (general purpose) dataflow
architectures the last few years. They were pretty hyped in the early
eighties. I'd like to hear some too, if there is something to hear.

Lucid? This is a data-flowish language and not an architecture, or am I
missing something?

>You can do many nifty things with dataflow if you boil stuff down well enough.
>It also appears to provide the only *truly* isofunctional representation of 
>algorithms (at least with simple transformations).  All that and it seems
>nearly intuitive (though not easy to write in I'll admit heartily, yet). 

I think it is a good thing to differ between dataflow *languages* and
dataflow *architectures*. Programs written in dataflow languages do not
necessarily require dataflow machines for their execution. They can very
well be compiled to more conventional parallel or sequential architectures.
I think dataflow languages have a future, especially single-assignment
languages since they seem to combine mathematical soundness with the
possibility of compilation into efficient parallel code. When it comes to
dataflow architectures, I'm less confident.

Bjorn Lisper