GCC 4.2.0 Status Report (2007-02-19)
Vladimir Makarov
vmakarov@redhat.com
Tue Feb 20 19:42:00 GMT 2007
Paolo Bonzini wrote:
>
>> I am agree, benchmarking is evil. My favorite benchmark is gcc
>> because it is my tool and I work on it. Compilation of gcc from
>> Spec2000 is >12% slower with df including last Paolo's patches
>> (which are a really big improvement).
>
>
> Interesting enough, 176.gcc has a pretty bad result for runtime too in
> SPEC2000:
>
> 176.gcc 1100 67.8 1622 1100 72.9 1509*
> 176.gcc 1100 68.1 1614* 1100 72.9 1509
> 176.gcc 1100 68.8 1600 1100 72.6 1515
>
>
> By your reasoning, there is some probability that fixing this one
> performance regression brings dataflow branch into shape for merging
> into mainline... (even though so much has changed since 2.7.2 which is
> used in SPEC2000).
>
Usually I check code size fo x86/x86_64. If it is bigger then something
is going wrong (it might be not true for itanium). It means more insns
(and probably performance degradation) and more compile time to process
insns (but i think for df generation more insns is only part of
slowdown). For df gcc code size is 0.5% bigger.
I'd like to use spec2006 gcc (as I remeber it is gcc 3.4) but running
spec20006 takes so long time for now. Still gcc-2.7 is good test for
big functions, switches etc. It is still a characteristic of modern gcc
versions.
More information about the Gcc
mailing list