Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uunet!ncrlnk!ncrcae!hubcap!david
From: david@cs.washington.edu (David Callahan)
Newsgroups: comp.parallel
Subject: Re: scalability of n-cubes, meshes (was: IPSC Communications)
Keywords: iPSC Parallel hypercubes meshes torus scalability
Message-ID: <7194@hubcap.clemson.edu>
Date: 27 Nov 89 13:32:56 GMT
Sender: fpst@hubcap.clemson.edu
Lines: 28
Approved: parallel@hubcap.clemson.edu

In article <7178@hubcap.clemson.edu> wilson@carcoar.Stanford.EDU (Paul Wilson) writes:
>Now could somebody summarize Dally's argument that 2D meshes
>(and toruses) are better?  I can see why you can wrap a 2D mesh
>around to make a torus one way, but can't you get much
>better packing by using a 3D mesh with its higher connectivity?
>It will have edges rather than wrapping around transparently,
>but that's the only way to avoid long wires in the limit.

We are building a machine with a 3d mesh. The "folding" that
eliminates edges in a 2d torus can be applied in three dimensions so
that the resulting cube has no edges or corners.

The machine is a shared-memory machine and the network is packet
switched rather than using worm-hole routing since the messages are
short. Latency to a remote memory module is 2 cycles per network node
traversed, one cycle routing and one cycle "on the wire". 

For a 256 processor machine, we plan a 16x16x16 cube. This size
assures adequate flux across any cut of the machine. For such a
machine, the expected one-way latency to memory is 12 hops or 24
cycles. Simulations indicate that contention raises this average only
slightly.

>Paul R. Wilson                         

-- 
David Callahan  (david@tera.com, david@june.cs.washington.edu,david@rice.edu)
Tera Computer Co. 	400 North 34th Street  		Seattle WA, 98103


Brought to you by Super Global Mega Corp .com