home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / compiler / 1396 < prev    next >
Encoding:
Internet Message Format  |  1992-08-17  |  4.6 KB
  1. Path: sparky!uunet!wupost!uwm.edu!rutgers!faatcrl!iecc!compilers-sender
  2. From: macrakis@osf.org (Stavros Macrakis)
  3. Newsgroups: comp.compilers
  4. Subject: Re: Why is compiled basic slower than C? (Basic is the future)
  5. Keywords: interpreter, performance
  6. Message-ID: <92-08-095@comp.compilers>
  7. Date: 17 Aug 92 17:53:11 GMT
  8. References: <92-08-042@comp.compilers> <92-08-073@comp.compilers>
  9. Sender: compilers-sender@iecc.cambridge.ma.us
  10. Reply-To: macrakis@osf.org (Stavros Macrakis)
  11. Organization: OSF Research Institute
  12. Lines: 84
  13. Approved: compilers@iecc.cambridge.ma.us
  14.  
  15. burley@geech.gnu.ai.mit.edu (Craig Burley) writes:
  16.  
  17.    I think interpreted languages _could_ compile well if _lots_ of effort
  18.    were expended.  However, that kind of effort probably isn't worth it --
  19.  
  20. Could you please define `interpreted language'?  Is it anything more than
  21. `a language whose first implementation was interpretive'?  In the present
  22. discussion, the language under question is Basic, whose first (and only
  23. for a long time) implementation was in fact compiled.  Other languages you
  24. might call `interpreted', like Lisp, Prolog, ML, and Snobol, in fact have
  25. very good compilers, which make major differences in runtime.
  26.  
  27.    the performance gains compared to the effort, that is -- when contrasted
  28.    to the effort expended in buying new, faster processors, 
  29.  
  30. The compiler speedup is complementary to the hardware speedup.
  31.  
  32.    making the interpreters run faster (often quite easy), 
  33.  
  34. Interpreters can, of course, be bummed (and often are).  But in many
  35. cases, this still leaves you far from the compiled speed.
  36.  
  37.                                                translating programs to
  38.    maintenable code in a language designed for compilation, and so on.
  39.  
  40. This is a possible approach.  However, you lose whatever advantages the
  41. `interpreted' language had, e.g. more appropriate abstractions, easier
  42. debugging, fast turnaround, etc.  There are of course compiler-based
  43. systems that provide easy debugging and fast turnaround e.g. most Lisp
  44. compilers, but also the CenterLine C (formerly Saber C) system.
  45.  
  46.    I remember a discussion with rms (GNU EMACS author) regarding TECO, the
  47.    language in which he first wrote EMACS.  TECO was (and still is,
  48.    primarily) an interpreted language (well, it's an editor, kind of like the
  49.    MS-DOS DEBUG program is a partition editor :-).
  50.  
  51. Teco is a weird language.  Most commands are single-character, and the
  52. main loop of the interpreter essentially dispatches directly to the
  53. relevant routine.  So it is a sort of human-readable (well, this is
  54. debatable, too) byte-compiled form.
  55.  
  56.    He told me about how someone we both knew had developed (or help
  57.    develop) a compiler for TECO and was prepared to demonstrate its
  58.    superiority in benchmarks.  But submitting one simple case
  59.    (something like deleting every other line in the file) proved the
  60.    opposite.
  61.  
  62. Teco is an extreme case, but even so, you could probably _slightly_ reduce
  63. runtime by compiling to machine code.  I certainly agree that in most
  64. cases, it would not be worthwhile to try to compile Teco code....
  65.  
  66.           (Of course, TECO is probably like APL in that the time
  67.    it takes to read in source code and figure out what it means is
  68.    minimal, as compared to C, FORTRAN, and COBOL.  So the penalty for
  69.    being an interpreter could be seen as significantly lower for terse
  70.    languages like TECO and APL,
  71.  
  72. Teco is not just terse, it requires no lexing or parsing.  Like APL, many
  73. of its operators are bulk operators and so most runtime is within their
  74. inner loops.  But even APL has been compiled with good results....
  75.  
  76.                 higher for verbose languages like
  77.    BASIC, FORTRAN, and COBOL.)
  78.  
  79.  
  80.    ...There is another major issue regarding interpretation which puts
  81.    both BASIC and C in the "compiled" camp: whether the running
  82.    program has a means to modify itself at run time.  LISP, for
  83.    example, belongs in the "interpreted" camp.
  84.  
  85. This is not really a problem.  The amount of Lisp code which actually
  86. modifies the program written by the programmer is just minuscule.  Much
  87. more code _generates_ pieces of Lisp, typically using the `macro' feature.
  88. But almost all cases of macro usage are handled straightforwardly in Lisp
  89. compilers.  There are a few cases where Lisp code generates code on the
  90. fly, then executes it.  This is handled by having an interpreter loaded
  91. along with the compiled code, and assuring that code can work correctly in
  92. such a mixed environment.  In fact, most Lisp implementations _assume_ a
  93. mixed environment....
  94.  
  95.     -s
  96. -- 
  97. Send compilers articles to compilers@iecc.cambridge.ma.us or
  98. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  99.