Nonlinear systems and nonlocal supercomputing
|
Prev: Call for Papers Reminder (extended): The World Congress on Engineering WCE 2010
Next: Call to stop spamming here
From: Anton Ertl on 15 Mar 2010 14:28 MitchAlsup <MitchAlsup(a)aol.com> writes: >On Mar 14, 1:25=A0pm, an...(a)mips.complang.tuwien.ac.at (Anton Ertl) >wrote: >> MitchAlsup <MitchAl...(a)aol.com> writes: >> >Consider a 1/2 meter sq motherboard with "several" CPU nodes with 16 >> >bidirectionial (about) byte wide ports running at 6-10 GTs. Now >> >consider a back plane that simply couples this 1/2 sq meter >> >motherboard to another 1/2 sq meter DRAM carring board also with 16 >> >bidirectional (almost) bite wide ports running at the same >> >frequencies. Except, this time, the DRAM boards are perpendicular to >> >the CPU boards. With this arrangement, we have 16 CPU containing >> >motherboards fully connected to 16 DRAM containing motherboards and >> >256 (almost) byte wide connections running at 6-10 GTs. .... >> Hmm, couldn't you have DRAM boards on both sides of the mainboard (if >> you find a way to mount the mainboard in the middle and make it strong >> enough). =A0Then you can have a computer like a normal-size fridge:-). > >{I believe} You need the DRAM boards to be perpendicular to the CPU >boards in order to create the massive bandwidth between the CPUs and >DRAMs. With 16 boards of each flavor, you have 256 independent FB-DIMM- >like channels providing the BW. The interconnecting "backplane" only >has wires connecting one port of one board with one port of another >straight through {with maybe some power, gnd, clocks,...} Hmm, several CPU boards. I originally thought about only one CPU board, with a relatively conventional arrangement. But reading your description again, maybe you mean: ############# DRAM boards ############# (we see only the one in front) ------------- backplane ||||||||||||| CPU boards ||||||||||||| (edge view, we see all of them in this view) ------------- motherboard Did I get that right? That would be 1/2m x 1/2m x 1m. - anton -- M. Anton Ertl Some things have to be seen to be believed anton(a)mips.complang.tuwien.ac.at Most things have to be believed to be seen http://www.complang.tuwien.ac.at/anton/home.html
From: Robert Myers on 15 Mar 2010 14:41 On Mar 14, 4:35 pm, "Del Cecchi" <delcec...(a)gmail.com> wrote: > > Golly, how much memory do you want. The 4TB quoted is about where the interesting science would begin. Assuming that you can do saxpy calculations from one box to another at a reasonable rate (contents of one box + constant * contents of a second box = contents of a third box, in effect treating the entire 4TB box as a gigantic vector register), you could do some interesting fundamental science with perhaps eight such boxes. No need for non- trivial data transfer outside each box, just a small number of box-to- box streaming transfers at each time step. Robert.
From: nmm1 on 15 Mar 2010 15:31 In article <2815d946-ef19-41d2-bd3c-87418a873caf(a)x12g2000yqx.googlegroups.com>, Robert Myers <rbmyersusa(a)gmail.com> wrote: >On Mar 14, 4:35=A0pm, "Del Cecchi" <delcec...(a)gmail.com> wrote: >> >> Golly, how much memory do you want. > >The 4TB quoted is about where the interesting science would begin. Some of us remember when that was said about 4 MB :-) Regards, Nick Maclaren.
From: Larry on 15 Mar 2010 17:02 On Mar 15, 5:17 am, Terje Mathisen <"terje.mathisen at tmsw.no"> wrote: > Larry wrote: > > Finally, I want to point out that good global communications can be > > done, it is just expensive. No magic is necessary. All you need to > > do is build a sufficiently large crossbar switch. These can have > > modular components, and it is "just" an engineering problem. Of > > course it's costs go as N**2 in the number of nodes. > > > Alternatively, you can build a fully configured fat tree, which only > > costs NlogN In either case, the cost of the communications is going > > to dominate the cost of the system at larger scale. You get logN > > latency with the fat tree, rather than constant, however. > > Hmmm? > > I would assume that when you get big enough, even a very large crossbar > could not scale much better than sqrt(N), since that is the increase in > wire distance? > > > > > This unfortunate tradeoff is why we keep getting 3D tori. They are > > easy to build, and they work for a range of scales, until they don't. > > SiCortex tried the Kautz graph, which scales better than the 3D torus, > > but is hard to wire. > > > So are there scalable solutions in which the communications costs only > > grow with the number of nodes? And which have low latency for all > > routes? One possibility is optical, where each node aims a laser at a > > mirror to hit the receiver on another node. There is collision > > avoidance work to be done, but there's no N**2 crossbar cost. > > The micro-mirror laser setup would seem to need a separate network to > handle setup of the links. > > If you want to steer the mirrors between every exchange, then the mirror > latency would probably dominate. > > TANSTAAFL > > Terje > I am allowing myself to dream of an optical phased array transmitter with electronic beam steering together with a fixed mirror. The feature sizes are already much smaller than visible wavelengths, after all. And if the receiver is omnidirectional, then you just have a collision management problem, ala original alohanet or ethernet and if you have a few wavelengths, perhaps that can be reduced. -L
From: Robert Myers on 15 Mar 2010 18:28
On Mar 15, 3:31 pm, n...(a)cam.ac.uk wrote: > In article <2815d946-ef19-41d2-bd3c-87418a873...(a)x12g2000yqx.googlegroups..com>, > Robert Myers <rbmyers...(a)gmail.com> wrote: > > >On Mar 14, 4:35=A0pm, "Del Cecchi" <delcec...(a)gmail.com> wrote: > > >> Golly, how much memory do you want. > > >The 4TB quoted is about where the interesting science would begin. > > Some of us remember when that was said about 4 MB :-) > I can provide specific answers as to why doing the math correctly (as opposed to "modeling") is highly desirable for that kind of scale separation, but this is not the appropriate forum. Robert. |