Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cbmvax!daveh
From: daveh@cbmvax.commodore.com (Dave Haynie)
Newsgroups: comp.sys.amiga.hardware
Subject: Re: A3000 CPU Wars!!
Message-ID: <22213@cbmvax.commodore.com>
Date: 6 Jun 91 19:33:28 GMT
References: <16888@helios.TAMU.EDU> <1991Jun5.060518.9683@news.iastate.edu> <1991Jun5.072620.18879@mintaka.lcs.mit.edu>
Reply-To: daveh@cbmvax.commodore.com (Dave Haynie)
Organization: Commodore, West Chester, PA
Lines: 45

In article <1991Jun5.072620.18879@mintaka.lcs.mit.edu> rjc@geech.gnu.ai.mit.edu (Ray Cromwell) writes:

>  Hmm, anyone wanna tell me how transputers work? (multiprocessing)?

Transputers define a loosely coupled multiprocessing system based on message
passing.  Essentially, each transputer has four hard message ports, which can
be used to send messages reasonably fast to four neighboring transputers.  This
is a decent architecture for building hypercube stype loose multiprocessing
systems.  There's really nothing that special about using a transputer rather
than some other system.  In fact, they're pretty weird.  The T800 series had
decent floating point, but weak integer instructions.  You do get some really
outrageous native MIPS figures for Transputer code, but each instruction does
much less work than a typical CISC or RISC instruction.  So a 68030 with a 
decent link chip as a periperheral would work better than an T800 at this.  
Which wouldn't have been a big issue if the Transputers had gone down in price,
since an '030 or any similar chip would need a link peripheral to do the same
job.  However, INMOS kept the pricing such that Transputers couldn't compete,
even with the built-in links.  As always, some people chose the Transputer
(easier solution) over a faster/cheaper but more work intensive solution based
on standard parts.  Others didn't, in fact, many of the hypercube architecture
machines are based around Intel processors.

On the other hand, INMOS was purchased by Thompson, and with some new money was
able to define a next generation Transputer.  It's not out yet, but the new
T9000 sounds much more intriguing.  It's considerably faster, so it could very
well stand a chance of competing with other modern CPUs on a 1:1 basis.  The
links are faster now, and they have a neat cross-point switch that works with
them.  The hardware supports virtual messages now.  Basically, a header in the
message structure indicates where it's going in your transputer network 
somehow.  When the message gets sent out the hardware port, it can get to its
ultimate destination through this message router, which will wait until a link
to the destination is free, create a temporary routing path from one to the
other, then dissolving it when the message has passed.  

Anyway, this new one looks to be pretty cool.  Yet, it doesn't solve the main
problem with loosely coupled system, which is, how to schedule work such that
it gets done faster on multiple processors than it does on a single one.  With
this model, you're basically dependent on splitting things at the task level.
This generally means that you have to write your code much differently, 
adapting the problem to the solution.  Some problems adapt, others don't. 

-- 
Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests"
   {uunet|pyramid|rutgers}!cbmvax!daveh      PLINK: hazy     BIX: hazy
	"This is my mistake.  Let me make it good." -R.E.M.