Conventional wisdom? (BASIC compilers and interpreters) (Programming Power)
by Tom Campbell

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.

What's most interesting is that Visual Basic for Windows 2.0 has such outstanding results on floating-point computations. It's much faster than even my Microsoft C version under DOS. Likewise, Quick-BASIC 4.5's interactive version, which uses the p-code method, somehow races past both its own compiled version and PowerBASIC's estimable code generator. Compiler Integer Floating-point Visual Basic for Windows 2.0 2.03 41.58 PowerBASIC (compiled) 0.22 70.52 QBASIC 3.36 71.89 QuickBASIC 4.5 (interactive) 1.49 66.50 QuickBASIC 4.5 (compiled) 0.16 79.65