From: macrakis@osf.org (Stavros Macrakis)
Subject: Re: Why is compiled basic slower than C? (Basic is the future)
Reply-To: macrakis@osf.org (Stavros Macrakis)
Organization: OSF Research Institute
Date: Fri, 14 Aug 1992 16:57:10 GMT
Keywords: Basic, interpreter, performance

scott@bbx.basis.com (Scott Amspoker) writes:

   We market a business-oriented BASIC-style language called BBx.  It is
   interpreted.  Although it is quite different from Microsoft BASIC there
   are still common qualities of any BASIC dialect.

   A few years ago there was some discussion about producing a compiler for
   it.  We found several reasons why a compiler would not be a great idea.
   The main reason is that the runtime dynamics of BASIC don't translate well
   to a compiled environment.  The most important aspects are dynamic
   string/array management and dynamic flow control involving error/exception
   handling.  The latter is especially hard to optimize.

Dynamic strings and arrays are supported in many programming languages
besides Basic.  Many of these languages have compilers (in fact, many have
only compilers and not interpreters).

Reasonable error and exception handling are also supported by many
languages.

   A C programmer tends to approach these things with a more "static" frame
   of mind resorting to a dynamic model only if it is really necessary (and
   knowing there will be a performance hit).  Furthermore, BASIC normally
   performs lots of runtime checks such as array subscripts and ranges.

Yes, so do other languages with compilers.  A compiled range check is much
more efficient than an interpreted one, especially when analysis shows (as
is often the case) that no check needs to be performed at all.

   Granted, a BASIC compiler could allow the option of turning these checks
   off but I'm assuming a proper semantical translation.

Proper semantic translation does not preclude correct optimizations.
Consider the following loop:

	FOR I = 1 TO N
	  A(I) = A(I)*3
	NEXT I

Array bounds checking need only be performed once (to assure that 1..N
fall within A's subscript bounds).

   Since our product is used primarily for business data processing
   applications which spend most of their time performing file and user i/o,
   the need for a compiler isn't as critical.  Indeed we have been known to
   beat some compiled languages in file-oriented benchmarks.

This is a quite different argument.  This shows why you believe you do not
need a compiler, but it does not show that Basic cannot be compiled.

   I just don't think interpreted languages compile well.

?!  There is no such thing as an `interpreted language'.  There are
interpretive implementations.  True, some languages lend themselves more
to easy interpretation, and others to easy compilation, but that's an
implementor's problem.  Anyway, Basic's first implementation (at
Dartmouth) was compiled....  You might consider Lisp to be an `interpreted
language'.  Compilers typically speed up Lisp programs by an order of
magnitude or so over interpretive execution, often more for numerical
code.  The resulting code may or may not be faster than compiled C or
Fortran code, but it is certainly faster than interpreted Lisp code.

   If they do then they really aren't exploiting the special strengths
   of interpretation.

The special strengths of interpretation have mostly to do with debugging
and quick turn-around of code corrections.

  You end up with the worst of both worlds.  --

Nonsense.  There are also many environments (e.g. most Lisp environments)
which permit mixing interpreted and compiled code.  This gives you in many
ways the best of both worlds.

	-s
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.