From: macrakis@osf.org (Stavros Macrakis)
Newsgroups: comp.compilers
Subject: Re: Why is compiled basic slower than C? (Basic is the future)
Keywords: interpreter, performance
Date: 17 Aug 92 17:53:11 GMT
Reply-To: macrakis@osf.org (Stavros Macrakis)
Organization: OSF Research Institute

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
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.