This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch] Merge to trunk from Graphite branch
On Mon, Mar 15, 2010 at 5:22 PM, Tobias Burnus <burnus@net-b.de>
wrote:
> On 03/15/2010 04:12 PM, Jack Howarth wrote:
>> On Mon, Mar 15, 2010 at 03:11:21PM +0100, Richard Guenther wrote:
>>> Updating the default x86 arch does bring you nothing (well, if
>>> you're not clueless in case you shouldn't build GCC yourself).
>>
>> ? ?I mentioned that because of the 2% improvement in the Polyhedron
>> 2005 benchmarks which coincided with the x86 arch changes which
>> enabled -msse2 across the board...
>>
>> http://gcc.gnu.org/ml/gcc/2010-03/msg00075.html
>
> I somehow doubt that the changing of the default has anything to do with
> it. I could well imagine that Toon uses -march=native or similar.
>
> And he wrote "last week" thus I do not see which one can really call it
> "coincide"; I think during that time there was at least one front-end
> patch which removed some unnecessarily generated array temporaries which
> can be very profitable in a hot loop (but had no visible influence on
> the Polyhedron runs). Maybe also some middle-end fix helped with a hot
> loop in Hirlam.
>
>>> As far as I know Graphite does not bring any performance advantages
>>> yet, so I see no reason to enable it by default.
>
> I agree; I think there are cases, where it is very profitable, but
> others, where it makes the program slower (cf. PR 38846). I hope that
> graphite in 4.6 will be suitable for enabling it by default. :-)
>
>>> I am not aware of any major vectorization missed-optimizations
>>> vs for example the Intel compiler for SPEC CPU 2006.
>
> Is there a place where one can find results for recent GCC and recent
> versions of the Intel compiler for the same system? I have frankly no
> idea how GCC and Intel compare on SPEC CPU 2000/2006 (or, for that
> matter, how GCC and IBM's XL compiler compare).
>
> (For the Polyhedron benchmark, Polyhedron itself shows that on geometric
> average GCC 4.4 and 4.3 are between 6% to 17% slower than the latest
> 11.1 Intel compiler [1]; on my dated AMD it's about 9% w/ GCC 4.5 vs
> ifort 11.1 and 6% w/ GCC 4.5 vs ifort 9.1; GCC gains 2% with -flto
> -fwhole-program -fno-protect-parens. And pathscale is 2 per-cent points
> faster than ifort 11.1 (i.e. 11% w.r.t. GCC).)
Note that a lot of the difference can be due to optimized math
routines that the Intel compiler uses by default. You can eliminate
(most) of that difference by LD_PRELOADing its libimf.so also
for the GCC built executables.
And of course it's always worth to analyze the reason for the slowness
on the testcase with the largest difference.
Richard.
> Tobias
>
> [1] http://www.polyhedron.co.uk/compare0html
>