🚀 go-pugleaf

In article <Bz5s9F.J32.2@cs.cmu.edu>, lindsay+@cs.cmu.edu (Donald Lindsay)
writes:

|>xm9@sdcc12.ucsd.edu (richard g. adair) writes:
|>>Even though a 730 will toast an 8 processor SGI!
|>
|>Never fear. SGI has promised a machine with 32 R4400's. Of course, HP
|>has promised a 16 CPU machine. It's finally about time to multithread
|>those codes, folks.

There are good reasons to multithread on single processors. All those programs
that make you wait while they do some low grade calculation or garbage
collection routine.


|>Oddly, although Crays have been multiprocessors for years, a lot of
|>programs only use one Cray processor. This is often largely a
|>function of incentive. One installation offered a big budget break to
|>parallel applications, and sure enough, almost everything suddenly
|>turned out to be parallelizable.

The big question is cost. If you do everything in single threads or using
trivial parallelism each processor requires enough memory to hold the trivial
partition of the problem. Programs like GEANT have trivial parallelism at the
event level which requires a database of >32 Mb. If you can split at a level
requiring only 1Mb then you can run 16 times faster for the same cost.

The reason is that 1Mb is approx same transistors as a processor (a bit more
actually...) So instead of 32Mb and 1 processor you can have 16 Processors with
1Mb ea.

The argument works better when you stick the processor on the same chip as the
RAM, no external memory bus at all, just an FDDI/HIPPI/whatever interface. that
means massive savings in production costs - none of those fiddly wires to put in
place... And in addition everything is onchip - no offchip penalty.


--

Phill Hallam-Baker