Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!lll-winken!ames!ames.arc.nasa.gov!lamaster
From: lamaster@ames.arc.nasa.gov (Hugh LaMaster)
Newsgroups: comp.arch
Subject: Re: Killer Micros and the TC2000
Message-ID: <45490@ames.arc.nasa.gov>
Date: 20 Mar 90 22:28:52 GMT
References: <51771@lll-winken.LLNL.GOV> <100598@convex.convex.com> <52661@lll-winken.LLNL.GOV> <798@dgis.dtic.dla.mil> <45408@ames.arc.nasa.gov> <53795@bbn.COM>
Sender: usenet@ames.arc.nasa.gov
Organization: NASA - Ames Research Center
Lines: 21

In article <53795@bbn.COM> slackey@BBN.COM (Stan Lackey) writes:
>In article <45408@ames.arc.nasa.gov> lamaster@ames.arc.nasa.gov (Hugh LaMaster) writes:
>>Speaking of architectural issues, how is the BBN TC 2000 working out?

>The peak bandwidth of the 63-node TC2000 depends upon where you
>measure it.

I agree.  Of course, Crays have no caches, but some Crays have local memory
and all Crays have vector registers and fairly numerous scalar registers.
You could call registers "programmable caches" to compare bandwidths :-)

My question was intentionally brief, but to be more specific: the architecture
obviously depends on the ability to parallelize in such a way that global
memory bandwidth is not the bottleneck.  How well is this working out?
etc. etc. etc.


  Hugh LaMaster, M/S 233-9,  UUCP ames!lamaster
  NASA Ames Research Center  ARPA lamaster@ames.arc.nasa.gov
  Moffett Field, CA 94035     
  Phone:  (415)604-6117