Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!udel!rochester!pt.cs.cmu.edu!gandalf.cs.cmu.edu!lindsay
From: lindsay@gandalf.cs.cmu.edu (Donald Lindsay)
Newsgroups: comp.arch
Subject: Re: iWarp Architecture Overview
Message-ID: <13340@pt.cs.cmu.edu>
Date: 9 Jun 91 03:40:53 GMT
References: <16477@ganymede.inmos.co.uk>
Organization: Carnegie Mellon
Lines: 24

In article <16477@ganymede.inmos.co.uk> 
	davidb@inmos.co.uk (David Boreham) writes:
>Although comparisons are clearly going to be made, I don't believe
>that the iWARP and Transputer are trying to solve the same
>problems.
>The more guys there are out there with silicon supporting 
>message-based MIMD systems, the better as far as I'm concerned.

Agreed, but note that iWarp isn't message-based.  It comes out of the
"systolic" idea, originally popularized by (oddly enough) Kung. A
torus of iWarp nodes *can* pass messages - and fairly well. However,
that's not the main idea. The intention is that raw untagged *values*
can be streamed around the interconnect.  The node design caters to
tight loops which read from registers that happen to be in-queues,
and write to registers that happen to be out-queues.

This programmable systolic behavior is sometimes incorrectly called
dataflow. It works very well for some problem domains, notably image
processing. The point to notice is that the streamed data may avoid
burning memory cycles. This worked well for the Columbia IQCD, which
was reporting a sustained 6 GFLOPS, more than a year ago. (Their
problem domain is *really* limited: they just do quark physics.)
-- 
Don		D.C.Lindsay 	Carnegie Mellon Robotics Institute