home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / compiler / 2122 < prev    next >
Encoding:
Internet Message Format  |  1993-01-08  |  3.7 KB

  1. Path: sparky!uunet!wupost!uwm.edu!ogicse!das-news.harvard.edu!spdcc!iecc!compilers-sender
  2. From: nickh@CS.CMU.EDU (Nick Haines)
  3. Newsgroups: comp.compilers
  4. Subject: Re: Compile Time vs. Run Time, Mixed Language Compiling, Fat Code
  5. Keywords: optimize, performance
  6. Message-ID: <93-01-049@comp.compilers>
  7. Date: 8 Jan 93 15:46:10 GMT
  8. Article-I.D.: comp.93-01-049
  9. References: <93-01-041@comp.compilers>
  10. Sender: compilers-sender@iecc.cambridge.ma.us
  11. Reply-To: nickh@CS.CMU.EDU (Nick Haines)
  12. Organization: School of Computer Science, Carnegie Mellon University
  13. Lines: 59
  14. Approved: compilers@iecc.cambridge.ma.us
  15.  
  16. Good grief; comp.compilers suddenly doubles in bandwidth. I won't bother
  17. to quote all of Paul Robinson's posts, but will reply to them all
  18. together.
  19.  
  20. 1. You seem to have a preoccupation with x86 architectures. Please do not
  21. assume that this is shared by most readers of comp.compilers. In
  22. particular, writing "we are inventing the wheel all over again ..." is
  23. assuming such a "we." The readers of comp.compilers include people who
  24. originally invented this wheel.
  25.  
  26. 2. Compilers that precompile or tokenise code during an editing phase are
  27. _not_ "cheating;" they are merely making best use of machine resources
  28. when the processor load is particularly low - you have to wait a million
  29. or more machine cycles for that next keystroke in an editing session.
  30. They are unusual outside of the PC market because almost everyone uses an
  31. unbundled editor (emacs, gnu-emacs, vi, etc) and because people want to
  32. share code with others who don't use the same environment. They are
  33. sometimes found in integrated compiler/environment packages, but these are
  34. expensive.
  35.  
  36. 3. Almost everyone who sells (or gives away) compilers _does_ have a
  37. "double vision" version; it's called optimization. Switch it off and your
  38. code compiles faster but runs slower.
  39.  
  40. 4. Use of a language with a good type system eliminates the
  41. edit-compile-bomb-edit cycle, replacing it with an
  42. edit-typecheck-edit-typecheck cycle. Typechecking is (in general) much
  43. faster than compilation because it includes no optimisation or code
  44. transformations. An SML program which successfully typechecks will not
  45. bomb at runtime.
  46.  
  47. 5. The problem with developing a uniform convention for argument passing
  48. is that the requirements of different languages are fundamentally
  49. different. For instance, it is a natural optimization in SML to keep
  50. function code addressses in closures and to pass the closure of a function
  51. to it in a register, as a hidden argument. This is a completely alien
  52. concept to FORTRAN ("closure? What's a closure?"). There are many other
  53. examples of different requirements.  There are mixed-language systems,
  54. such as Poplog, which provides POP-11, Prolog, Common Lisp, SML (and
  55. another language). I have no idea how they manage (say) the SML/Prolog
  56. calling convention; I see no trivial solution.
  57.  
  58. 6. You suggest that because compiler writers often work for compiler
  59. companies rather than hardware companies, they either (a) don't know how
  60. to tweak the hardware in the best way or (b) can't be bothered.  (a) is
  61. almost never true these days: hardware specs are very good and working on
  62. a compiler for an architecture is one of the best ways to learn that
  63. architecture inside out (working on an OS is even better).  (b) is
  64. occasionally true, but is surely a consequence of insufficient resources:
  65. it seems users are happy to settle for compilers that don't tweak the
  66. hardware as much as they might; if users demanded the best possible
  67. performance they would have to pay more but would presumably get it (this
  68. does in fact happen, and is why some compilers cost a _lot_ more than
  69. others).
  70.  
  71. Nick Haines nickh@cmu.edu
  72. -- 
  73. Send compilers articles to compilers@iecc.cambridge.ma.us or
  74. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  75.