Re: Faster compilation speed

[Mike Stump <mrs at apple dot com>]

On Friday, August 9, 2002, at 01:15 PM, Aldy Hernandez wrote:
> > + extern int flag_speed_compile;
> So, you want to introduce a flag to do faster compilation?  Why not
> spend your time making the current infrastructure faster?
Because we cannot attain the goal without he flag.  I welcome an 
existence proof the the contrary.  :-)

Ok, that's a cheap comment...  Let me expound some...  There may be 
things that the existing compiler does, that if it didn't do, it would 
compile faster.  These types of changes represent a 100% speed up of 
the affected code.  A few well placed 100% speedups are more effective 
and take less time than improving a more substantial portion of the 
code by 10 or 20%.  Also, by bypassing a few pieces of code, the impact 
and the chance of damaging the code is reduced.  I anticipate that the 
changes will be easier, go faster, and will be obviously more correct 
than redoing complex pieces of code.  Also, without the flag, any 
change that shortens a search, or limits how far we look for something 
and so on would be exposed to the user by default, which, we may not 
want to do a first.  Maybe for reliability reasons, maybe so that we 
don't have to explain to them why things are `different'.  And, even if 
we did that, it would _still_ have to be conditional on a flag, it is 
just that the flag it would be conditional on would be called optimize.

Let's take my combine elision patch.  This patch makes the compiler 
generate worse code.  The way in which it is worse, is that more stack 
space is used.  How much more, well, my initial guess is that it is 
less than 10% worse.  Not too bad.  Maybe users would care, maybe they 
would not.  Hard to know.  My first priority is to find such code and 
make it faster.  But the conservative in me says, don't mess with the 
user, not yet.  One can think of the work as in two phases.  The first 
phase is to just identify the raw hot spots.  We can do that quickly, 
and in such a way as to be very safe.  The next phase, would have an 
domain expert steeped in the traditions of the specific algorithm under 
study review the `cost' of the algorithm, and find innovative ways to 
improve it at a more fundamental level.  However, for compilation 
speed, they're going to have to do better than the 100% speed up of the 
`removed' code, otherwise, I'm not going to hit my 6x goal.

This 6x goal is very aggressive.  Think of the goal as a 36x goal.  
That is in fact the reality.  I want it 36x faster.  One would need to 
speed the compiler up 10% 34 times to get there.  The saving grace is I 
am treating the first 6x as an already solved problem, PFE.  I merely 
have to get the next 6x solved.

Now, let me retreat some from the above.  I'm not going to place all 
code to speed up compilation under this flag.  Only code that makes the 
generated code worse.  Just because some of the work I expect to do may 
fall under the above category doesn't mean that I will avoid or not do 
the other type of work.  I cannot honesty say how much of my code will 
fall in one category or the other.  For example, if I find a lookup 
routine that is doing linear searching for identifiers over a 100 MB 
memory image for the header files and page faulting in all 100 MB of 
that image, and the thing searching only wanted two pieces of data 
(yes, we do that folks, check out cxx_finish_file), I will propose a 
hash, or another chain, or ...

Now, if people want -O0, the default to be that option, I can do that.  
That is up for discussion.  Conservatively I can change 
flag_speed_compile to !optimize in a few seconds, if in a few months we 
decide that is what we want to do.  Going the other way around, I will 
be hard pressed to `undo' the use of !optimize.  What do people think, 
on by default at -O0, keyed off optimize, or keyed off a ne flag?

I hope that explains my thinking a little bit more.  Comments?  
Anything sound wrong?  And unforeseen dangers?