home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / arch / 11625 < prev    next >
Encoding:
Internet Message Format  |  1992-12-14  |  2.9 KB
  1. Path: sparky!uunet!mcsun!sunic!dkuug!diku!torbenm
  2. From: torbenm@diku.dk (Torben AEgidius Mogensen)
  3. Newsgroups: comp.arch
  4. Subject: Re: uniprocessor design ceiling
  5. Message-ID: <1992Dec14.111417.309@odin.diku.dk>
  6. Date: 14 Dec 92 11:14:17 GMT
  7. References: <1gbpjrINNsq6@girtab.usc.edu>
  8. Sender: torbenm@thor.diku.dk
  9. Organization: Department of Computer Science, U of Copenhagen
  10. Lines: 54
  11.  
  12. plaw@usc.edu (Patrick Law) writes:
  13.  
  14. >Correct me if I am wrong. For the last 20 years, we have 4-bit 
  15. >microprocessor, CISC, cache, RISC, superscalar, superpipeline,
  16. >etc. Have we reached a point of diminishing return in uniprocessor
  17. >design? Could we still get a speedup of "X" every "N" years like
  18. >before? The above evolutions are just experiences we learnt in
  19. >building big machines like the IBM 390. I think it is a time for
  20. >MIMD and a change of serial programming style.
  21.  
  22. That has been the opinion of many people for many years. Why then, has
  23. it not happened? My guess is that there are two reasons:
  24.  
  25. 1) Micro-parallelism (superscalarity etc.) in uniprocessors has kept
  26. them going faster at a steady rate for many years.
  27.  
  28. 2) Implementing "traditional" programming styles on MIMD architectures
  29. has met with little success. Languages that support parallel
  30. programming style has not gained widespread acceptance for
  31. "mainstream" programming.
  32.  
  33. The real questions are then
  34.  
  35. ad. 1) How long can we expect this to continue.
  36.  
  37. ad. 2) Can we expect any change is this area.
  38.  
  39. My guess is that uniprocessors will continue to increase their speed
  40. at approximately the present rate by use of new fabrication
  41. technologies and extended micro-parallelism. The relative cost will
  42. however rise faster than the speed. We have already passed the point
  43. where multiprocessors based on cheap processors offer more raw
  44. performance per $ than fast uniprocessors. The programming problems of
  45. the multiprocessors has kept these from gaining popularity.
  46.  
  47. This brings us directly to the other question. I fear that we will
  48. never get acceptable compilers for low-level languages (like C) for
  49. MIMD machines. So, as long as people insist on using these languages,
  50. they (and as a consequence, we) are stuck with uniprocessors. People
  51. need a very good incentive for changing to a completely different
  52. programming language and style, and the only good incentive for the
  53. people who matter (the industry) is money. So until someone produces a
  54. parallel machine that runs the programs people want at twice the speed
  55. and half the cost of competing uniprocessor designs, there is not
  56. likely to be any change.
  57.  
  58. Specialist areas will in all likelihood use more parallel machines,
  59. but these tend to be very expensive systems, either because they
  60. combine a huge number of processors (like CM2) or because they are
  61. based on (relatively few) expensive high-end uniprocessors (like CM5).
  62. These systems are not likely to compete against workstations and
  63. high-end PCs.
  64.  
  65.     Torben Mogensen (torbenm@diku.dk)
  66.