This is the mail archive of the
mailing list for the GCC project.
Re: Faster compilation speed
- From: Mike Stump <mrs at apple dot com>
- To: Aldy Hernandez <aldyh at redhat dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Fri, 9 Aug 2002 15:28:19 -0700
- Subject: Re: Faster compilation speed
On Friday, August 9, 2002, at 01:15 PM, Aldy Hernandez wrote:
Because we cannot attain the goal without he flag. I welcome an
existence proof the the contrary. :-)
+ 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?
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?