Re: GCC 3.3 compile speed regression - AN ANSWER

[Linus Torvalds <torvalds at transmeta dot com>]

On Tue, 11 Feb 2003 tm_gccmail@mail.kloo.net wrote:
> On Tue, 11 Feb 2003, Linus Torvalds wrote:
> > 
> > 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.

Well, it doesn't, actually. 

One of the things the VFS layer is very careful about is to try to _share_ 
the data as much as at all possible (which is quite a lot, actually) 
between all layers. It basically never copies data - EVER. 

And this includes things like parsing the filename and creating the hash
for it at the same time - and then using the resultant dentries not just
for the VFS layer caching, but actually passing that very cache down to
the filesystem directly exactly because we do not want to have different
layers using different data structures.

The thing is, when it comes to the kernel, we _have_ looked at 
performance. In fact, that's usually the first thing we look at, 
especially when it comes to data structures. Because data structures 
really are the thing that determine how fast you can go.

Also, I think you'll find that newer kernels tend to be _faster_ than 
older ones. And yes, that's again because it's one of the main concerns. 
So I think your argument falls flat on its face.

> There is a reason why the code exists in multiple formats during
> compilation; some transformations are easier done in some formats than
> others.

And this will slow things down. There's no question about it. At dubious
gain - because you _can_ plot a line where gcc is getting slower and
slower to compile over the last few years, but you can _not_ plot a 
line which shows the resulting improvement in resultant code quality.

One of the main things that people complained about in the kernel mailing
list was that not only did the compiler get slower, but the code
_generated_ also got bigger and slower. That is indeed what the thread got 
started about.

			Linus