Re: Why is compiled basic slower than C? (Basic is the future)

burley@geech.gnu.ai.mit.edu (Craig Burley) writes:


      I think interpreted languages _could_ compile well if _lots_ of effort
      were expended. However, that kind of effort probably isn't worth it --


Could you please define `interpreted language'? Is it anything more than
`a language whose first implementation was interpretive'? In the present
discussion, the language under question is Basic, whose first (and only
for a long time) implementation was in fact compiled. Other languages you
might call `interpreted', like Lisp, Prolog, ML, and Snobol, in fact have
very good compilers, which make major differences in runtime.


      the performance gains compared to the effort, that is -- when contrasted
      to the effort expended in buying new, faster processors,


The compiler speedup is complementary to the hardware speedup.


      making the interpreters run faster (often quite easy),


Interpreters can, of course, be bummed (and often are). But in many
cases, this still leaves you far from the compiled speed.


                                                                                              translating programs to
      maintenable code in a language designed for compilation, and so on.


This is a possible approach. However, you lose whatever advantages the
`interpreted' language had, e.g. more appropriate abstractions, easier
debugging, fast turnaround, etc. There are of course compiler-based
systems that provide easy debugging and fast turnaround e.g. most Lisp
compilers, but also the CenterLine C (formerly Saber C) system.


      I remember a discussion with rms (GNU EMACS author) regarding TECO, the
      language in which he first wrote EMACS. TECO was (and still is,
      primarily) an interpreted language (well, it's an editor, kind of like the
      MS-DOS DEBUG program is a partition editor :-).


Teco is a weird language. Most commands are single-character, and the
main loop of the interpreter essentially dispatches directly to the
relevant routine. So it is a sort of human-readable (well, this is
debatable, too) byte-compiled form.


      He told me about how someone we both knew had developed (or help
      develop) a compiler for TECO and was prepared to demonstrate its
      superiority in benchmarks. But submitting one simple case
      (something like deleting every other line in the file) proved the
      opposite.


Teco is an extreme case, but even so, you could probably _slightly_ reduce
runtime by compiling to machine code. I certainly agree that in most
cases, it would not be worthwhile to try to compile Teco code....


(Of course, TECO is probably like APL in that the time
      it takes to read in source code and figure out what it means is
      minimal, as compared to C, FORTRAN, and COBOL. So the penalty for
      being an interpreter could be seen as significantly lower for terse
      languages like TECO and APL,


Teco is not just terse, it requires no lexing or parsing. Like APL, many
of its operators are bulk operators and so most runtime is within their
inner loops. But even APL has been compiled with good results....


higher for verbose languages like
      BASIC, FORTRAN, and COBOL.)




      ...There is another major issue regarding interpretation which puts
      both BASIC and C in the "compiled" camp: whether the running
      program has a means to modify itself at run time. LISP, for
      example, belongs in the "interpreted" camp.


This is not really a problem. The amount of Lisp code which actually
modifies the program written by the programmer is just minuscule. Much
more code _generates_ pieces of Lisp, typically using the `macro' feature.
But almost all cases of macro usage are handled straightforwardly in Lisp
compilers. There are a few cases where Lisp code generates code on the
fly, then executes it. This is handled by having an interpreter loaded
along with the compiled code, and assuring that code can work correctly in
such a mixed environment. In fact, most Lisp implementations _assume_ a
mixed environment....


-s
--

Return to the comp.compilers page.
Search the comp.compilers archives again.