This month, I decided to test some of the conventional wisdom about BASIC
compilers and interpreters: that compilers are faster than interpreters, that
floating-point computations are faster than integer, and that Windows slows
everything down.

A compiler takes the input language (BASIC, in this case) and converts it to
an equivalent machine code representation so that it can be run directly on
the target processor (the 386, 286, or whatever CPU runs your machine). A
compiler needs to run only once, because it creates an executable file. Unless
the manufacturer says otherwise (and no major compiler company does), you're
licensed to sell or give the executable to anyone you want essentially without
restriction.

Interpreters, on the other hand, don't create executables. An interpreter
consumes as much of the program as it can and runs that portion, then eats as
much of the next part of the program as it can. You always need an interpreter
as a host environment--as well as the operating system--to run an interpreted
program. Normally, you're not allowed to distribute or sell your interpreted
program unless the customer already owns the interpreter or you sell a copy of
the interpreter along with your program. That's not always the case, though.
Sometimes you're given licensing rights to a special version of the
interpreter called a runtime version that can only, in accordance with its
name, run programs. It can't let the user change them.

The advantages of a compiler seem obvious. So why bother with interpreters at
all? Because compilers normally make you wait awhile each time you run a
program while it's compiled and linked, whereas interpreters usually omit
those steps--just load and go. What if you wanted to write a compiler for both
the Macintosh and the PC? One way to do this would be to "compile" to a chip
that doesn't exist--an idealized hybrid between the Mac and the PC. Then write
a tiny program that converts--interprets, actually--this mythical machine code
to executable statements for the target processor. Now, what do you have--a
compiler or an interpreter? Microsoft calls this a compiler. It's taken an
approach very like the one I just described (called a p-code machine for
historical reasons) on Visual Basic for Windows, Word Basic, Access Basic, and
other dialects, starting with Quick- BASIC. As you might imagine, it's not
intrinsically as efficient as direct compilation. But life isn't that simple.
For example, floating-point code is notoriously inefficient on PCs without a
math coprocessor--so inefficient that compiled floating-point code could be
slower than well-written interpreted floating-point code, right? Well . . .
Right. Sometimes.

The conventional wisdom has it, for example, that Visual Basic is slower than
compiled BASIC, but that it's not terribly important except in the case of
situations such as tight loops; the overhead of Windows is where most of the
extra time is consumed. DOS compilers are faster and create smaller code, or
so it goes, but they don't offer all the advantages of Windows.

I ran a program similar to this one (it differed slightly for each dialect) in
which an empty. FOR loop using integer counters ran 500,000 times and then a
similar loop using BASIC floating-point counters ran. Dim iCount1, iCount2 As
Integer Dim dCount1, dCount2 As Double t = Timer For iCount1 = 1 To 1000 For
iCount2 = 1 To 500 Next iCount2 Next iCount1 PRINT "Integer Loop count to
500,000 in seconds: " + Str$(Timer - t) t = Timer For dCount1 = 1 To 1000 For
dCount2 = 1 To 500 Next dCount2 Next dCount1 PRINT "Double loop count to
500,000 in seconds: " + Str$(Timer - t)

See the table above. Results will vary, of course, because my machine
configuration (25-MHz 486SX) is probably different from yours.