Re: Using C as a back end

"Joachim Durchholz" <joachim_d@gmx.de>
31 Oct 2000 14:43:27 -0500

          From comp.compilers

Related articles
[17 earlier articles]
Re: Using C as a back end nr@labrador.eecs.harvard.edu (2000-10-31)
Re: Using C as a back end sweeks@my-deja.com (Stephen T. Weeks) (2000-10-31)
Re: Using C as a back end zs@ender.cs.mu.oz.au (2000-10-31)
Re: Using C as a back end thp@cs.ucr.edu (Tom Payne) (2000-10-31)
Re: Using C as a back end engler@Stanford.EDU (2000-10-31)
Re: Using C as a back end anton@mips.complang.tuwien.ac.at (2000-10-31)
Re: Using C as a back end joachim_d@gmx.de (Joachim Durchholz) (2000-10-31)
Re: Using C as a back end conway@ender.cs.mu.oz.au (2000-11-01)
Re: Using C as a back end kst@cts.com (Keith Thompson) (2000-11-01)
Re: Using C as a back end rhyde@cs.ucr.edu (Randall Hyde) (2000-11-01)
Re: Using C as a back end rhyde@cs.ucr.edu (Randall Hyde) (2000-11-01)
Re: Using C as a back end vbdis@aol.com (2000-11-04)
Re: Using C as a back end joachim_d@gmx.de (Joachim Durchholz) (2000-11-04)
[5 later articles]
| List of all articles for this month |

From: "Joachim Durchholz" <joachim_d@gmx.de>
Newsgroups: comp.compilers
Date: 31 Oct 2000 14:43:27 -0500
Organization: Compilers Central
References: 00-10-148 00-10-164 00-10-205
Keywords: performance, comment
Posted-Date: 31 Oct 2000 14:43:27 EST

Conor O'Neill <ONeillCJ@logica.com> wrote:
> Joachim Durchholz <joachim_d@gmx.de> didn't write:
> >[Actually, in many compilers the scanner is the slowest part because
> >it's the only thing that has to look at every character in the source
> >file. -John]
>
> I thought that the scanner is the slowest part, because the scanner
> looks at every character in the headers multiple times, once for each
> compilation module.
>
> Pre compiled headers presumably speed this up considerably, but the
> systems I use don't have them.


Precompiled headers do indeed save a lot of time. On a
small-to-medium-size project (some 10.000 LoC) this made the
difference between 30 seconds and two minutes or so, mostly because it
was a Windows project and windows.h includes several megabytes of
definitions.


The mingw32 package for gcc uses a bare-bones version of windows.h
that leaves out comments and whitespace, resulting in a file of about
300K IIRC. This is mainly for copyright reasons, but the mingw32
people say that this also helps to speed up the compilation process.


OTOH when compared to, say, Turbo Pascal, half a minute for
recompiling just a few thousand lines of code is still ridiculously
slow. I compiled 100.000s of lines in a minute on a 16-MHz machine
years ago, it should be a snap on today's multi-100MHz machines. I
don't know what's eating up all this time; there are two potential
sources: 1) Language differences 2) Optimization


I don't think that (1) is responsible for many differences; C doesn't
have anything that Pascal has. If anything, then Pascal is a bit more
difficult to generate code for (it's got nested functions), but that's
nothing that should really affect the time spent generating code.
(Anybody with real experience in this area please correct me!)


(2) is a good candidate. Turbo Pascal always emitted horribly bad
code. So it seems that many C compilers spend a *lot* of time
optimizing the generated code. Anybody with concrete numbers from
compiler passes to back or falsify this hypothesis?


Regards,
Joachim
[I believe that you'll find that a remarkable amount of the difference
is that Borland designed Turbo Pascal to be fast. When they mutated
Wizard C into Turbo C, it got a lot faster as well due to straightforward
tricks such as cacheing include files in RAM. -John]


Post a followup to this message

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