This is the mail archive of the
mailing list for the GCC project.
Re: GCC-4.5.0 comparison with previous releases and LLVM-2.7 on SPEC2000 for x86/x86_64
- From: Jan Hubicka <hubicka at ucw dot cz>
- To: Vladimir Makarov <vmakarov at redhat dot com>
- Cc: "gcc.gcc.gnu.org" <gcc at gcc dot gnu dot org>
- Date: Thu, 29 Apr 2010 18:42:30 +0200
- Subject: Re: GCC-4.5.0 comparison with previous releases and LLVM-2.7 on SPEC2000 for x86/x86_64
- References: <4BD9B2EB.firstname.lastname@example.org>
> GCC-4.5.0 and LLVM-2.7 were released recently. To understand
> where we stand after releasing GCC-4.5.0 I benchmarked it on SPEC2000
> for x86/x86-64 and posted the comparison of it with the
> previous GCC releases and LLVM-2.7.
> Even benchmarking SPEC2000 takes a lot of time on the fastest
> machine I have. So I don't plan to use SPEC2006 for this in near
> You can find the comparison on
> http://vmakarov.fedorapeople.org/spec/ (please just click links at the
> bottom of the left frame starting with link "GCC release comparison").
> If you need exact numbers, please use the tables (the links to them
> are also given) which were used to generate the corresponding bar
> In general GCC-4.5.0 became faster (upto 10%) in -O2 mode. This is
> first considerable compilation speed improvement since GCC-4.2.
> GCC-4.5.0 generates a better (1-2% in average upto 4% for x86-64
> SPECFP2000 in -O2 mode) code too in comparison with the previous
> release. That is not including LTO and Graphite which can gives even
> more (especially LTO) in many cases.
> GCC-4.5.0 has new big optimizations LTO and Graphite (more
> accurately graphite was introduced in the previous release).
> Therefore I ran additional benchmarks to test them.
> LTO is a promising technology especially for integer benchmarks for
> which it results in smaller and faster code. But it might result in
> degradations too on SPECFP2000 mainly because of big degradations on a
> few benchmarks like wupwise or facerec. Another annoying thing about
> LTO, it considerably slows down the compiler.
Seems like something sensitive for setup. In our daily benchmarking LTO
fatster on wupwise (2116 compared to 1600), and facerec is 2003 compared to
2041 (so about the same).
Did you test with -fwhole-program?