GCC 3.3 compile speed regression - AN ANSWER

[Jan Hubicka]

> The list archive entry I pointed to does have profile-driven cases too, 
> but there are totally fair comparisons there (ie plain "icc -O2"). The 
> most interesting case is
> 
> 	*Local* Communication latencies in microseconds - smaller is better
> 	-------------------------------------------------------------------
> 	Host                 OS 2p/0K  Pipe AF     UDP  RPC/   TCP  RPC/ TCP
> 	                        ctxsw       UNIX         UDP         TCP conn
> 	--------- ------------- ----- ----- ---- ----- ----- ----- ----- ----
> 	p70        Linux 2.4.18 0.770 4.111 7.30  13.1  32.8  18.9  44.7 69.1
> 	p70        Linux 2.4.18 0.700 4.405 7.51  13.2  32.8  19.2  45.6 70.1
> 	p70        Linux 2.4.18 0.730 4.392 7.37  13.5  32.8  19.3  44.7 70.8
> 	gcc32      Linux 2.4.18 0.780 4.224 7.33  15.7  35.3  21.6  47.5 72.9
> 	gcc32      Linux 2.4.18 0.870 4.327 7.56  15.7  35.6  21.8  47.1 73.0
> 	gcc32      Linux 2.4.18 0.900 4.377 7.55  15.6  35.5  21.9  48.0 72.8
> 
> note how UDP latency (which is basically the same as performance - it's
> the speed path through the networking stack) improved by roughly 15%. The
> TCP numbers also improved by 10%+ (the RPC cases also improved, but since
> those cases have much more of a user-level footprint, the kernel compiler
> obviously won't impact them as much).
> 
> 10% is quite a bit. 15% is a lot.
> 

Yes, it is.  I would really like to know what happends here.

> It may also be that on a P4 the real costs end up being things like 
> synchronization primitives etc that are not something the compiler can do 
> anything about..

This is intersting.  In our tests P4 seems to generally execute pretty
poorly on GCC gnerated code (relative to ICC one), when compared to
Athlon and P3.  Adding some extra P4 optimizations would be easy and
desirable.

> 
> On the whole, I'm pretty happy about gcc, don't get me wrong. People on 
> the gcc lists only see me when I complain and moan, so you guys probably 
> think I hate your guts and would rather see you all burn in hell. It ain't 
> so, and I'm sorry for ragging on you.

I am not taking it badly.  Reason why I am asking for examples that goes
wrong is not because I disagree with the fact that they do exist.  What
I would like to see is more cooperation between the kernel and GCC
developers.  Kernel developers are one of relatively few people who
actually reads code generated by GCC and worry about it's quality, so
they can provide pretty good feedback for improving GCC in case we get
to better communication.

It is probably not going to directly help the compile time issues we are
discussing, but still I would love to see it happen.

Honza