GCC 3.3 compile speed regression - AN ANSWER

[Jan Hubicka]

> 
> On Wed, 12 February 2003, at 02:29, Joe Buck wrote:
> > On Tue, Feb 11, 2003 at 11:55:33AM -0000, Rob Taylor wrote:
> > > g++ is so incredibly slow - observe:
> > >
> > > hellow.cpp:
> > > #include <iostream>
> > >
> > > int main()
> > > {
> > >     std::cout << "Hello, world!\n";
> > > }
> > >
> >
> > Congrats, you just timed the compiler, the assembler, and the linker,
> > not just the compiler.  The compiler is too slow, but if you want to time
> > just the compiler you need to write
> >
> > time g++-3.1 -S hellow.cpp
> 
> ok, my bad, for the current purposes.
> (NB - any chance of documenting -time? - it isn't in Option Summary)
> (also, before i start, can anyone tell me whether pch works for c++ yet? if
> so i'll repeat all these tests on mainline with pch on)
> 
> more detail:
> 
> robt@hal:~$ g++-3.1 -time  hellow.cpp
> # cc1plus 1.40 0.06
> # as 0.00 0.01
> # collect2 0.19 0.02
> robt@hal:~$ time g++-3.1 -S  hellow.cpp -o hellow.cpp.s
> 
> real    0m1.577s
> user    0m1.490s
> sys     0m0.090s
> robt@hal:~$
> 
> I did some quick comparisons with the functionally equivalent
> 
> #include <stdio.h>
> 
> main()
> {
>    printf ("Hello World!\n");
> }
> 
> as to what time gets spent in as and ld (just looking at user cpu secs as
> are dominant factor)-
> (avtime times 20 executions of command and avarages results)
> 
> robt@hal:~$ ./avtime.sh g++-3.1 -S hellow.cpp -o hellow.cpp.i
> 1.41667
> robt@hal:~$ ./avtime.sh g++-3.1 hellow.cpp -o hellow.cpp.o
> 1.64
> robt@hal:~$ ./avtime.sh g++-3.1 -S hellow.c -o hellow.c.i
> 0.06
> robt@hal:~$ ./avtime.sh g++-3.1  hellow.c -o hellow.c.o
> 0.25
> 
> even though gcc generates nearly 10 times as much asm for the cpp case, the
> total time spent in as+ld is pretty much constant.
> 
> 
> the same timings on some production c++ using qt (not including ld)
> 
> ~/avtime.sh
> g++-3.1 -g -DfDEBUG -DfTRACES_ON -DCOMPILE_DEBUG -DLINUX -fsigned-char -D_IS
> OC99_SOURCE -DUNICODE -fexceptions -fmessage-length=0 -Wall -W -Wno-reorder 
> -Wno-unknown-pragmas -Wno-unused -Wno-non-template-friend -fPIC -DAUTOTEST_O
> N -DLANGUAGE_SUPPORT_ON -DQT_DLL  -I$GUT_DIR/components -I$QTDIR/include -c
> autopalette_window.cpp -o autopalette_window.cpp.o
> 21.5467
> 
> devel@hal:~/gut/components/gui_windows$ ~/avtime.sh
> g++-3.1 -g -DfDEBUG -DfTRACES_ON -DCOMPILE_DEBUG -DLINUX -fsigned-char -D_IS
> OC99_SOURCE -DUNICODE -fexceptions -fmessage-length=0 -Wall -W -Wno-reorder 
> -Wno-unknown-pragmas -Wno-unused -Wno-non-template-friend -fPIC -DAUTOTEST_O
> N -DLANGUAGE_SUPPORT_ON -DQT_DLL  -I$GUT_DIR/components -I$QTDIR/include -S
> autopalette_window.cpp -o autopalette_window.cpp.s
> 19.7133
> 
> 
> so thats a couple of seconds spent in gas for approx 4.6 meg of assembler.
> 
> I'm thinking that perhaps the best development solution would probably be a
> speed branch, with a dedicated machine performing nightly timings on a
> number of suitable test cases. I may be able to dedicate some
> (machine+devel) time to such a thing.

Dedicate machine for timmings would be very usefull in any case even for
mainline.  Some analysis tool that would generate emails when the
comipler slows down should IMO help a lot.  That is at least my
experience with SPEC testing Andreas and Diego do.

Since we do have the testers, the code queality has improved
considerably (at lest newer GCC doesn't commonly produce worse code as
it used to be the case for earlier releases), but still there are number
of slowdowns that remains unanalyzed, because people like I who actually
look at the graphs regulary don't have time to track them down all and I
guess number of people miss it because there is no notification about
the regressions.  I tried to look over major hops in the graph in gcc
3.1 period and track down the reasons.  It was relatively easy thing to
do and brought considerable speedup just before the code freeze.  I
didn't had time to do as much for 3.3 unfrotunately, hope I will be able
to do so for 3.4.

I am not sure how reliable the data can be analysed - some jumps in the
graph are obvious, other are caused by temporarily broken compiler on
some of the tests and number of them are just noise.  I think someone
with knowledge of statistics should be able to put something together.

It would be also good to have testcases more designed for performance
issues - SPEC has problem of being mostly done in C, so C++ performance
is not tested too much and many developers can't access the sources so
it makes it dificult to track it down.

Just my 2 cents :)
Honza
> 
> Rob Taylor