Path: utzoo!utgpu!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!agate!bionet!apple!bloom-beacon!tut.cis.ohio-state.edu!ukma!gatech!hubcap!boulder!tramp!hassell
From: boulder!tramp!hassell@ncar.UCAR.EDU (Christopher Hassell)
Newsgroups: comp.parallel
Subject: Re: Hmm!  ( CM info / also req. dataflow info )
Summary: some ideas
Message-ID: <3467@hubcap.UUCP>
Date: 7 Nov 88 19:05:01 GMT
Sender: fpst@hubcap.UUCP
Lines: 72
Approved: parallel@hubcap.clemson.edu

Hello there,

I'm a nosy undergrad and I happened upon a book on the CM in, of all places,
the Boulder Public Library.  I looked over it a while ago and am just working
from memory here.

In article <3405@hubcap.UUCP> bjornl@tds.kth.se (Bj|rn Lisper) writes:
>In article <3363@hubcap.UUCP> vrdxhq!ogccse.ogc.edu!pase@uunet.UU.NET
>(Douglas M. Pase) writes:
 
>%I'm not sure this is correct.  As I recall, there are two networks available
>%for use in the CM.  The first is a NEWS network (either a torus or a mesh, I
>%don't remember which), and the second is indeed a hypercube.  
 
I think the NEWS was a torus.

>I think the NEWS network is really embedded within the hypercube (and the
>local cluster crossbars) using binary-reflected Gray encoding. Thus it
>doesn't have any physical connections of its own.
 
If I remember I think that there was a true-to-life NEWS network in it.
I don't remember if it was outside clusters only or seamless though.

>%One big difference is that the CM hypercube is synchronous (i.e., a 12-D
>%network requires 12 steps to transfer data, even if the target is a nearest
>%neighbor).
 
>I wonder if this is true. If there is congestion, messages will have to wait
>until the line is free. Therefore it might take more than twelve cycles to
>complete an instruction. This implies that there must be some mechanism by
 
>Any TMC people out there who know the facts?

>Bjorn Lisper

Well I ain't one but I'll give it a try.  As I recall there were 12 lines
running in and out of a routing node (one for each cluster).  I think(?) 
that there weren't any major cycles requiring message completion but
there definately was a synchronous cycle for each forwarding of a message.

It basically caused a node to accept a message into its memory (small)
and try to reconcile the bits left unadjusted to its own address.  If 
the address matched I believe it simply accepted it and put it into the
cluster to finish its routing (also to get it out of the node-net).  

Nodes certainly could be kept busy and by some obscure scheme queue their 
messages out (handling included reversing a correct bit if necessary!)
The mechanism was impressive and made overloading node's memory impossible
as I recall.

I can certainly go get another look and post it or reply to any questions
via mail.  The book was simplistic in a way but described routing relatively
well, although it certainly wasn't a tech manual.

-------

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.

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). 

(Arrgh, ..shoost..ziiip..sheesss..ziiiiip..ziip...) 
Okay, got me suit on.  Flame away, if desired!!!

(Oh and yes that's a Cylon smiley)
-----------------------------------------------------------------------------
Disclaimer: Well these *obviously* couldn't be myyy opinions! Really!-)
p.s. I'll figure out what ta put in this stupid .sig file later
-----------------------------------------------------------------------------