Re: GCC 3.3 compile speed regression - AN ANSWER

[<tm_gccmail at mail dot kloo dot net>]

On Tue, 11 Feb 2003, Linus Torvalds wrote:

> In article <Pine.LNX.4.33.0302112331070.27761-100000@kern.srcf.societies.cam.ac.uk> you write:
> >On Tue, 11 Feb 2003, Michael S. Zick wrote:
> >
> >> 1) Give the problem/solution the recognition it deserves in the form of
> >> a separate branch, solely for this specific purpose.
> >
> >We *have* the faster-compiler-branch, created at the same time as
> >gcc-3_4-basic-improvements-branch
> ><http://gcc.gnu.org/ml/gcc/2002-08/msg01575.html>.  It just hasn't been
> >used, whereas BIB was extensively used.
> 
> I bet the reason it didn't get used is simply that making the compile
> faster is a hell of a lot harder than just adding a few improvements.
> 
> The thing is, if you want to make gcc faster, you have to bite the
> bullet and throw out code that doesn't perform well.  And you have to
> _remove_ phases of optimization, instead of adding new ones.  Having
> different phases where you operate on different kinds of data structures
> (ie tree -> ssa -> rtl) is just fundamentally slow, as you have to
> marshall the data into the right format for the next phase (which is
> likely bad for caches too). 

Well, if you apply this line of reasoning to Linux, then you could remove
stuff such as the virtual filessytem layer, since all it does convert data
from one format to another. In fact, you might even remove the filesystem
and allow processes to write directly to the disk...this would improve I/O
performance significantly.

There is a reason why the code exists in multiple formats during
compilation; some transformations are easier done in some formats than
others. For example, taking the filesystem analogy, it would be very
difficult to do quotas if people were allowed to write to the disk
directly. Also, exact file sizes would be difficult to determine since
files would be written on sector alignment.

It's not fair to criticize abstraction without knowing the full benefits
gained from the particular abstraction.

Toshi