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

scott@bbx.basis.com (Scott Amspoker)
Thu, 13 Aug 1992 15:41:07 GMT

          From comp.compilers

Related articles
Why is compiled basic slower than C? (Basic is the future) Glenn_Johansson@f313.n203.z2.fidonet.cd.chalmers.s (1992-08-11)
Re: Why is compiled basic slower than C? (Basic is the future) jch@rdg.dec.com (1992-08-12)
Re: Why is compiled basic slower than C? (Basic is the future) hywang@apple.com (Hao-yang Wang) (1992-08-12)
Re: Why is compiled basic slower than C? (Basic is the future) maniattb@cs.rpi.edu (1992-08-12)
Re: Why is compiled basic slower than C? (Basic is the future) macrakis@osf.org (1992-08-12)
Re: Why is compiled basic slower than C? (Basic is the future) scott@bbx.basis.com (1992-08-13)
Re: Why is compiled basic slower than C? (Basic is the future) macrakis@osf.org (1992-08-14)
Re: Why is compiled basic slower than C? (Basic is the future) burley@geech.gnu.ai.mit.edu (1992-08-14)
Why is compiled basic slower than C? tchannon@black.demon.co.uk (1992-08-15)
Re: Why is compiled basic slower than C? (Basic is the future) dbenn@leven.appcomp.utas.edu.au (1992-08-15)
Re: Why is compiled basic slower than C? (Basic is the future) pardo@cs.washington.edu (1992-08-15)
Re: Why is compiled basic slower than C? (Basic is the future) macrakis@osf.org (1992-08-17)
[6 later articles]
| List of all articles for this month |

Newsgroups: comp.compilers
From: scott@bbx.basis.com (Scott Amspoker)
Organization: BASIS International, Ltd., Albuquerque NM USA
Date: Thu, 13 Aug 1992 15:41:07 GMT
References: 92-08-042 92-08-049
Keywords: Basic, performance

jch@rdg.dec.com (John Haxby) writes:
>Glenn_Johansson@f313.n203.z2.fidonet.cd.chalmers.se writes:
>|> [How much slower is compiled Basic than C, and why?]
>
>There has been a lot of work put into optimizing C compilers: the efforts
>of FSF, Sun and MIPSCO to mention but three. There hasn't been a great
>deal of work put into optimizing BASIC compilers, at least not that I know
>of.
>
>There seems to be a more general problem though: compilers of high-level
>languages tends to produce optimal machine code, whereas compilers of
>low-level languages tend to produce sub-optimal machine code.


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.


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.
Granted, a BASIC compiler could allow the option of turning these checks
off but I'm assuming a proper semantical translation.


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.


I just don't think interpreted languages compile well. If they do then
they really aren't exploiting the special strengths of interpretation.
You end up with the worst of both worlds.
--
Scott Amspoker
Basis International, Albuquerque, NM
scott@bbx.basis.com
--


Post a followup to this message

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