home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / arch / 9415 < prev    next >
Encoding:
Internet Message Format  |  1992-09-07  |  1.9 KB
  1. Xref: sparky comp.arch:9415 comp.lang.misc:3068
  2. Path: sparky!uunet!dtix!darwin.sura.net!spool.mu.edu!sdd.hp.com!uakari.primate.wisc.edu!copper!aspen.craycos.com!sog
  3. From: sog@craycos.com (Steve Gombosi)
  4. Newsgroups: comp.arch,comp.lang.misc
  5. Subject: Re: Goals, Cost, and Flexibility (was Re: "Training" of programmers)
  6. Message-ID: <1992Sep14.175555.285@craycos.com>
  7. Date: 14 Sep 92 17:55:55 GMT
  8. References: <JAN.92Sep12155439@pallas.neuroinformatik.ruhr-uni-bochum.de> <9225808.14389@mulga.cs.mu.OZ.AU> <BuJnA9.JCA@mentor.cc.purdue.edu>
  9. Organization: Cray Computer Corporation
  10. Lines: 24
  11.  
  12. In article <BuJnA9.JCA@mentor.cc.purdue.edu> hrubin@mentor.cc.purdue.edu (Rubin Herman) writes:
  13. >
  14. >This doubling is for the minis and micros, which are finding it possible to
  15. >come closer to the speeds of fast mainframes.  The speed improvement from 
  16. >the CRAY 1 to their latest machines is more in using multiple processors,
  17. >but this will eventually run into physical limits.  The switching time has
  18. >only tripled in a dozen years; there may be breakthroughs, but another 20
  19. >doublings may very well reach basic physical limits in size, speed, and
  20. >number of processors.
  21.  
  22. I believe you meant switching *speed*. A lot of the improvement from the Cray-1
  23. to the original (2 processor) X-MP was due to speed-ups in the original
  24. processor design. The faster clock was a minor improvement. Tripling
  25. the number of vector<->memory paths, adding flexible chaining, reduction
  26. of vector startup overhead, and allowing
  27. chaining to memory operations helped a lot more. 
  28.  
  29. Throwing processors at a problem certainly helps, if the problem is 
  30. sufficiently parallel to benefit and the overhead of multitasking it is 
  31. sufficiently low. Everyone won't benefit - if your problem is only 90%
  32. parallel, you can only speed it up by a factor of 10 whether you have
  33. 16 processors or 16 million - even *if* the multitasking overhead is zero.
  34.  
  35. Steve 
  36.