🚀 go-pugleaf

In 
>To: hall!K.GP.CS.CMU.EDU!Donald.Lindsay
> In general, today's hypercubes are bandwidth-heavy compared to conventional
> machines. A 256-node Butterfly has an 8K-bit-wide path to memory. (Yes, I
> know it's not quite a cube.) A 1024-node NCUBE has a 16K-bit-wide path to
> memory.  A 64K-processor Connection Machine has a 64K-bit-wide path. This is
> somewhat more than any Cray - regardless of where in the Cray you choose to
> measure.

Yes, but...  You describe how wide the data-paths are, but not what the
bandwidth is (bandwidth defined as bits/second transferred).  A Cray Y-MP
has 8 CPUs x 4 ports apiece x 166.7M cycles per second x 64 bits/reference
for a total memory bandwidth of ~340Gbits/sec.  What are the clock cycles
of the NCUBE, etc., (to multiply by datapath widths to get bandwidth)?

> I recently heard a talk by Gil Weigand of Sandia National Labs. He claims
> considerable success in getting near-linear scaleup on his NCUBE/10. In
> particular, he mentioned a Laplacian solver which was deliberately memory
> intensive. It used 128 times the memory ( 2MB --> 256MB ) in return for 300
> times less computation. He claimed his time-to-result was dramatically
> better than on the Sandia Cray, even though the Cray is the superior in
> MFLOPS.
> This raises several interesting questions.
> - Could this algorithm work on the Cray, or is the massive memory bandwidth
>   the whole secret ?

The 256MB won't fit in main memory on a Cray-1 or X-MP.  Was this just a
in-core/out-of-core difference?  (Granted, it's probably easier to put
a larger memory on a distributed memory machine than a shared memory
machine.)

> I'd call this good news.

I agree.  We still don't know enough about what kinds of machines
are best for what kinds of problems.


Steve Reinhardt		{inhp4,sun!tundra}!cray!spr
Cray Research, Inc.  	spr@hall.cray.com@uc.msc.umn.edu
Mendota Heights, MN
		Standard disclaimer.