Is There Still a Need for "Turbo" Compilers?

Those of us who have been around a while still remember the miracle of
Borland's "Turbo" languages. They were so much faster than anything
else available at the time that they made the compile/link step take a
negligible amount of time. Given how slow I/O was in those days, this
was a very welcome development.

Turbo languages sacrifice code optimization for quick build time, and
are more suited for development and debug stages that final code
production. They also avoid I/O by keeping the output of compiler
stages in memory.

However, these days there aren't any "Turbo" language implementations
that I'm aware of. Is this because modern hardware is so fast that it
isn't worth developing compilers and linkers optimized for speed? By
using proper command line arguments to gcc, can you get quasi-Turbo
performance compared to using arguments that result in
highly-optimized code?

John Ousterhout, the inventor of Tcl/Tk, is the founder of a company
that produces software that optimizes parallelizing of the commands in
makefiles, which is one way to speed up the building of large software
packages. But, this doesn't do anything to the compilers themselves.

But, how fast could a compiler be given today's vast amount of virtual
memory and multiple-core CPUs?

Cordially,
--
Jon Forrest
Research Computing Support
College of Chemistry
173 Tan Hall
University of California Berkeley
Berkeley, CA
94720-1460
510-643-1032
jlforrest@berkeley.edu

Jon Forrest wrote:

> Those of us who have been around a while still remember the miracle
> of Borland's "Turbo" languages. They were so much faster than
> anything else available at the time that they made the compile/link
> step take a negligible amount of time. Given how slow I/O was in
> those days, this was a very welcome development.

TurboC still was much slower than TurboPascal, due to the "nature" of
the languages.


> Turbo languages sacrifice code optimization for quick build time,
> and are more suited for development and debug stages that final code
> production. They also avoid I/O by keeping the output of compiler
> stages in memory.

A RAD environment still will try to keep all (compiled) information in
memory, it's a matter of the integration of the compiler into the IDE.
And a matter of the compiler options, of course, where a syntax check
or debug build must not be optimized, in contrast to a release build.

> However, these days there aren't any "Turbo" language
> implementations that I'm aware of. Is this because modern hardware
> is so fast that it isn't worth developing compilers and linkers
> optimized for speed? By using proper command line arguments to gcc,
> can you get quasi-Turbo performance compared to using arguments that
> result in highly-optimized code?

In the new CodeGear BDS it's not the compiler, that makes long
turnaround times, it's the framework with all the plugins
(ErrorInsight...). A very different situation from stand-alone
compilers...

> John Ousterhout, the inventor of Tcl/Tk, is the founder of a company
> that produces software that optimizes parallelizing of the commands
> in makefiles, which is one way to speed up the building of large
> software packages. But, this doesn't do anything to the compilers
> themselves.

Right, the compilers nowadays are as fast as possible, but instead of
introducing parallelism into the compiler, a modern (multi-core...)
CPU also can run multiple compilers at a time. The bottleneck then
will be the disk I/O, which (in detail for C header files) can be
"widened" by a MRU file cache in the OS, as implemented at least in
Windows.

In 1993 I "tested" the Win3.1 multitasking capabilities, running up to
7 programs at the same time, for reading data from a tape, converting
the raw data, and writing the results to an MO drive. I played the
operator, inserting the next tape or MO cartridge, starting the
conversion programs for the new input, and reorganizing the
directories and filenames prior to writing them to the MO drive. While
all the drives were busy most of the time, I had enough time left for
bookkeeping and playing a patience in parallel, and I'm pretty sure
that this wouldn't change nowadays :-)


> But, how fast could a compiler be given today's vast amount of virtual
> memory and multiple-core CPUs?

As John stated, nowadays JIT compilers are as powerful as the old
compilers in the Turbo era have been. Here the disk I/O is minimized
by an appropriate precompilation, that (hopefully) eliminates the need
for accessing many disk based header files during JIT compilation. The
JIT compilers also can run in parallel to the application itself,
making better use of multi-core CPUs.

Just my 0.02$ ;-)

DoDi
[The main reasons that the Turbo compilers were fast is that they buffered
most of the file I/O in RAM, including tokenized versions of header files.
Not sure how that would work on today's VM systems where the dividing line
between RAM and disk is so blurry.  Doesn't GCC already start by mapping in
the whole source file? -John]

Jon Forrest <jlforrest@berkeley.edu> wrote:
> However, these days there aren't any "Turbo" language implementations
> that I'm aware of. Is this because modern hardware is so fast that it
> isn't worth developing compilers and linkers optimized for speed? By
> using proper command line arguments to gcc, can you get quasi-Turbo
> performance compared to using arguments that result in
> highly-optimized code?

Given the amount of algorithms with non-linear complexity in an
optimizing compiler, I doubt that an optimizing compiler will ever
result in "Turbo" performance.

For a recent compiler that puts emphasis on compilation speed, have a
look at Tiny C: http://fabrice.bellard.free.fr/tcc/. It claims to
compile a 2004 Linux kernel in 10 seconds.

On the other hand, have a look at modern GCCs: in spite of all those
fancy optimizations, they keep getting slower and slower.

I agree that fast compilers seem to become a lost art, and I think
that this is unfortunate. Fast turn-around cycles are a major factor
in productivity, and you can still do the final build with an
optimizing compiler (or with optimization enabled).

I guess this is why I am using mostly interpreters these days,
but I digress.

Nils
--
Nils M Holm <nmh@t3x.org> -- http://t3x.org/nmh/

On 2008-03-17, Jon Forrest <jlforrest@berkeley.edu> wrote:

> However, these days there aren't any "Turbo" language implementations
> that I'm aware of. Is this because modern hardware is so fast that it
> isn't worth developing compilers and linkers optimized for speed? By
> using proper command line arguments to gcc, can you get quasi-Turbo
> performance compared to using arguments that result in
> highly-optimized code?

Note that at least a significant part of the speed differences between
"Turbo*" and gcc don't come from optimization but the integration of
the various stages of the compiling process.

Jon Forrest wrote:

> Is this because modern hardware is so fast that it
> isn't worth developing compilers and linkers optimized for speed?

The Mac OS X development package Xcode has, for the development phase, a
"zero-link" feature - the code is not linked at all, except at need at
runtime.

> By using proper command line arguments to gcc, can you get
> quasi-Turbo performance compared to using arguments that result in
> highly-optimized code?

When developing in Haskell, one can use the interpreter Hugs, or GHCi,
and then make binaries using the compiler GHC. The programs runhugs and
runhaskell can interpret Haskell scripts.

Hans Aberg

Jon Forrest wrote:
> Those of us who have been around a while still remember the miracle of
> Borland's "Turbo" languages. They were so much faster than anything
> else available at the time that they made the compile/link step take a
> negligible amount of time. Given how slow I/O was in those days, this
> was a very welcome development.
>
> Turbo languages sacrifice code optimization for quick build time, and
> are more suited for development and debug stages that final code
> production. They also avoid I/O by keeping the output of compiler
> stages in memory.
>
> However, these days there aren't any "Turbo" language implementations
> that I'm aware of.

The lcc-win compiler is one of the fastest compilers under the windows
system (linux/AIX versions exist too).

It is fast because it keeps everything in memory, without building any
intermediate files.

Compared to gcc the compilation speed ratio is 1:6 or 1:10, it
depends.

> Is this because modern hardware is so fast that it isn't worth
> developing compilers and linkers optimized for speed?

No. It is because compilers and languages are becoming so BLOATED that
they loose all perspective from their user's needs.

> By using proper command line arguments to gcc, can you get
> quasi-Turbo performance compared to using arguments that result in
> highly-optimized code?


"quasi Turbo" is an exaggeration here. That compiler is one
of the slowest compilers in existence.

> John Ousterhout, the inventor of Tcl/Tk, is the founder of a company
> that produces software that optimizes parallelizing of the commands in
> makefiles, which is one way to speed up the building of large software
> packages. But, this doesn't do anything to the compilers themselves.
>
> But, how fast could a compiler be given today's vast amount of virtual
> memory and multiple-core CPUs?

Download lcc-win from the link below and see how fast it is.
http://www.cs.virginia.edu/~lcc-win32

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

Jon Forrest <jlforrest@berkeley.edu> wrote:
>
>However, these days there aren't any "Turbo" language implementations
>that I'm aware of. Is this because modern hardware is so fast that it
>isn't worth developing compilers and linkers optimized for speed?

Perhaps you should looks at scripting language implementations, where the
code has to be compiled every time it is run, so compilation needs to be
fast. For example, the Lua interpreter compiles code to a register-based
virtual machine so its front end has a structure very similar to a simple
stand-alone compiler.

Tony.
--
f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/
CROMARTY FORTH TYNE DOGGER: NORTHWEST 5 TO 7, PERHAPS GALE 8 LATER IN DOGGER
.
MODERATE OR ROUGH. SHOWERS, SOME WINTRY. MAINLY GOOD.

Nils M Holm wrote:

(snip)

> I agree that fast compilers seem to become a lost art, and I think
> that this is unfortunate. Fast turn-around cycles are a major factor
> in productivity, and you can still do the final build with an
> optimizing compiler (or with optimization enabled).

It seems that compilers not requiring huge amounts of memory is also a
lost art.

There are people trying to get gcc running on S/370, with its 24 bit
address space and maybe 8M available to a user process.  It seems that
gcc can't compile itself in 8M.

The solution, then, is a new architecture based on S/370 but with more
address bits and a modified MVS to run on it.

-- glen
[My, that's bloated.  Sixth edition Unix could compile itself in
about 32K. -John]

On Mar 17, 11:52 am, Jon Forrest <jlforr...@berkeley.edu> wrote:

> Those of us who have been around a while still remember the miracle of
> Borland's "Turbo" languages. > But, how fast could a compiler be given
today's vast amount of virtual
> memory and multiple-core CPUs?

You can try it.  The old Borland turbo compilers are still out there,
and they run fairly well in an XP cmd shell.

I loved those old compilers and knew them very well.  Some random
observations...

Source was parsed directly from the editor buffer.

The code from the pascal compilers was poor enough to have been
produced in one LR pass (in the parser).  Not generating an IR is a
tremendous advantage.

At least the early TP versions had major components (perhaps the whole
compiler) hand coded in assembly language.  They were "compile-and-
go."  The machine code was built in memory and executed directly.
They only wrote to disk to generate the executable.

Because the parsers stopped on the first error, they needed no error
recovery mechanism, and they had minimal error messages.  No doubt
this helped speed.  I always felt the approach made a lot of sense.
If it only takes 1/10 of a second to compile a 2000 line source, then
why bother finding more than one error at a time?

I'm pretty sure from the way they aborted on larger sources that the
relative decline in performance of the Turbo C/C++ compilers wrt
Pascal was from adopting an IR.

The Turbo C++ compiler was the old Stroustrop dialect with no
templates or multiple inheritance - considerable simplifications.

Folks ought not to be so rough on gcc.  It grew up over a long period
with many authors.  This is not a recipe for speed.  It pays
significant bills for its generality.  The data structures are very
rich to handle many languages and processors.  Even with optimizations
off, there are overheads for optimization.

It will be interesting to see the performance of a minimal compiler
built with LLVM and the engineered from scratch clang front end.
There is a nice Google video where Chris Latner talks about some of
the things that make gcc hungry for memory and time.
http://video.google.com/videoplay?d...156852099786640

> It seems that compilers not requiring huge amounts of memory is also a
> lost art.

I'll disagree.  It's a matter of goals, not forgetfulness.  There's
lots of people who know how to write compilers that run quickly and
compilers that don't need much space and even compilers that produce
good code.  I'll bet they'd be happy to do it too, if you paid them.

But all three?  That's tough.

Preston