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

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
--

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