This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Faster compilation speed

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?

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]