home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / lang / scheme / 2777 < prev    next >
Encoding:
Internet Message Format  |  1992-12-16  |  2.5 KB
  1. Path: sparky!uunet!mitech!gjc
  2. From: gjc@mitech.com (George J. Carrette)
  3. Newsgroups: comp.lang.scheme
  4. Subject: Re: Are interpreters now as fast as compiled code used to be?
  5. Message-ID: <4078@mitech.com>
  6. Date: 16 Dec 92 17:23:31 GMT
  7. References: <4051@mitech.com> <FEELEY.92Dec14215701@zohar.ai.mit.edu> <4067@mitech.com> <FEELEY.92Dec15153031@zohar.ai.mit.edu>
  8. Organization: Mitech Corporation, Concord MA
  9. Lines: 48
  10.  
  11. In article <FEELEY.92Dec15153031@zohar.ai.mit.edu>, feeley@zurich.ai.mit.edu (Marc Feeley) writes:
  12. > Well a factor of 3 for the last decade is clearly not valid but for
  13. > the next 5 years it might be.  DEC's Alpha introduced this year (200 MIPS
  14. > or so) is about 3 times faster than last year's HP9000/700 (70 MIPS).
  15. > If next year DEC comes out with their BIPS processor (1000 MIPS) my
  16. > factor of 3 seems about right.
  17.  
  18. You need to track a given manufacturer, not jump from one to another,
  19. because the computer guys are not -really- leapfrogging each other.
  20. They just appear to be for marketting purposes. Also "benchmark rot"
  21. is involved as people play games with funky preprocessors that don't
  22. always mean much for what good programmers would write.
  23.  
  24.   [Also, people with real work to do hardly ever win by jumping from
  25.   one machine manufacturer to the next ever year or two].
  26.  
  27. Look at what SUN has done with 680xx and SPARC since say 1983 to present.
  28.  
  29. And HP the same, starting with their 680xx machines and their new RISC line.
  30.  
  31. And for the longest time curve, you have the DIGITAL VAX line. Where this
  32. years VAXSTATION is about the same speed as last years HP RISC machine.
  33. And this years lowest-end ALPHA about 3 times faster than that. Ah,
  34. the famous factor of 3.
  35.  
  36. > Clearly this increase in performance will level off at some point in
  37. > the future. 
  38.  
  39. No, I think we have seen a pretty steady factor of 100 over the last
  40. decade. That works out to be about a factor of 1.6 per year.
  41.  
  42. Glitches are caused by project start up, manufacturing, and other
  43. lead-time delays. Where you can get shifts of two years, typically.
  44. And 1.6 squared is about your factor of 3.
  45.  
  46. > When that happens the additional factor of 100 or so
  47. > provided by compilers will be more valuable.
  48.  
  49. I don't agree that compilers give a factor of 100. 
  50. On simple numerical stuff, yes. But that is easy operator
  51. specialization. Even interpreters can do that.
  52.  
  53. > Note that parallel
  54. > processing does not change the argument because what counts is the
  55. > number of MIPS you can get with your budget.
  56.  
  57. Bring back timesharing?
  58.  
  59.