Re: Performance degradation on g++ 4.6
On Fri, Jul 29, 2011 at 7:56 PM, Oleg Smolsky wrote:
> Hi there, I have compiled and run a set of C++ benchmarks on a CentOS4/64
> box using the following compilers:
> a) g++4.1 that is available for this distro (GCC version 4.1.2 20071124
> (Red Hat 4.1.2-42)
> b) g++4.6 that I built (stock version 4.6.1)
>
> The machine has two Intel quad core processors in x86_64 mode (/proc/cpuinfo
> attached)
>
> Benchmarks were taken from this page:
> http://stlab.adobe.com/performance/
>
> Results:
> - some of these tests showed 20..30% performance degradation
> (eg the second section in the simple_types_constant_folding test: 30s
> -> 44s)
> - a few were quicker
> - full reports are attached
>
> I would assume that performance of the generated code is closely monitored
> by the dev community and obvious blunders should not sneak in... However, my
> findings are reproducible with these synthetic benchmarks as well as
> production code at work. The latter shows approximately 25% degradation on
> CPU bound tests.
We do monitor quite an extensive set of benchmarks - but as always certain kind
of applications may slip through - I'll have a look at the mentioned benchmark
and see whether it's easy to integrate with our testing at gcc.opensuse.org.
Richard.
> Is there a trick to building the compiler or using a specific -mtune/-march
> flag for my CPU? I built the compiler with all the default options (it just
> has a distinct installation path):
> ../gcc-%{version}/configure --prefix=/work/tools/gcc46
> --enable-languages=c,c++ --with-system-zlib --with-mpfr=/work/tools/mpfr24
> --with-gmp=/work/tools/gmp --with-mpc=/work/tools/mpc
> LD_LIBRARY_PATH=/work/tools/mpfr/lib24:/work/tools/gmp/lib:/work/tools/mpc/lib
>
> Are there any published benchmarks? I'd appreciate any advice or pointers.
>
> Thanks in advance,
> Oleg.
>
Re: Re: patch: don't issue -Wreorder warnings when order doesn't matter
2011/7/29 Daniel Marjamäki : > Hello! > >> Why doesn't it matter in this case but it matters when the initializer >> are non-constant? > > It doesn't matter because the program will behave the same no matter > if the initializations are reordered or not. Logically it will behave > just as the user expects no matter if he expects reordering or not. > > When one initializer is non-constant there might be a dependency > between the two initializations and the wrong order might be a bug. > I would like to silence such warnings also, but I don't want to try to > determine if there is dependencies or not. > > >> If you don't want to fix up your code, just compile it with -Wno-reorder. > > I don't want to use -Wno-reorder , because then I won't see the real > problems. Don't get me wrong, I like this check. > > > When gcc generates noise I think it is better to fix gcc than to fix my code. It's not noise - the warning is useful in it current form. > The only reason I can think of to keep this noise is for purely > stylistic reasons. Somebody might think it is a stylistic problem to > initialize members backwards. But then -Wreorder should also warn > about common assignments and I doubt anybody wants that. This is not a stylistic issue, it is about finding potential problems as early as possible. I want to know the mem-initializers are in the wrong order ASAP so I can correct them immediately, not when I change the initializer to a non-constant. What reason do you have for NOT fixing your code when the initializers are in the wrong order? The code might behave as expected, but it's still misleading to write the mem-initializers in one order if the compiler ignores it and uses a different order. I would object to changing the behaviour, or if it changes then it should be controllable so I can continue to get the current behaviour, e.g. -Wreorder=0 does what you propose, -Wreorder=1 does what we have now, and -Wreorder is equivalent to -Wreorder=1
Re: Performance degradation on g++ 4.6
Hi Oleg, I had some performance degradation with 4.6 as well. However, I was able to cure it by using -finline-limit=800 or 1000 I think. However, this lead to a code size increase. Were the old higher-performance binaries larger? IIRC, setting finline-limit=n actually sets two params to n/2, but I think you may only need to change 1 to get the old performance back. --param max-inline-insns-single defaults to 450, but --param max-inline-insns-auto defaults to 90. Perhaps you can get the old performance back by adjusting just one of these two parameters, or by setting them to different values, instead of the same value, as would be achieved by -finline-limit. -BenRI
Re: Re: patch: don't issue -Wreorder warnings when order doesn't matter
Quoting Jonathan Wakely : I would object to changing the behaviour, or if it changes then it should be controllable so I can continue to get the current behaviour, e.g. -Wreorder=0 does what you propose, -Wreorder=1 does what we have now, and -Wreorder is equivalent to -Wreorder=1 That sounds somewhat obscure (e.g. why isn't -Wreorder=0 the same as -Wno-reorder), and at some point people might demand negative values for more discriminating checks and floating point values for in-between choices. I think more descriptive would be: -Wreorder=nonconst and -Wreorder=any If someone miraculously cheats Rice's theorem, or wants to propose to get as close as possible to tell if reordering has a semantic effect as is feasible to tell in a compiler, you could call it -Wreorder=relevant or somesuch.
Re: Re: patch: don't issue -Wreorder warnings when order doesn't matter
On 30 July 2011 15:56, Joern Rennecke wrote: > Quoting Jonathan Wakely : > >> I would object to changing the behaviour, or if it changes then it >> should be controllable so I can continue to get the current behaviour, >> e.g. -Wreorder=0 does what you propose, -Wreorder=1 does what we have >> now, and -Wreorder is equivalent to -Wreorder=1 > > That sounds somewhat obscure (e.g. why isn't -Wreorder=0 the same > as -Wno-reorder), and at some point people might demand negative values > for more discriminating checks and floating point values for in-between > choices. > > I think more descriptive would be: > -Wreorder=nonconst and -Wreorder=any > > If someone miraculously cheats Rice's theorem, or wants to propose to get > as close as possible to tell if reordering has a semantic effect as is > feasible to tell in a compiler, you could call it -Wreorder=relevant or > somesuch. Sure, call it -Wreorder=bikeshed if you want to. I don't care what it's called but I want the current behaviour, so if -Wreorder changes I want it to be optional.
Re: Re: patch: don't issue -Wreorder warnings when order doesn't matter
2011/7/30 Joern Rennecke : > Quoting Jonathan Wakely : > >> I would object to changing the behaviour, or if it changes then it >> should be controllable so I can continue to get the current behaviour, >> e.g. -Wreorder=0 does what you propose, -Wreorder=1 does what we have >> now, and -Wreorder is equivalent to -Wreorder=1 > > That sounds somewhat obscure (e.g. why isn't -Wreorder=0 the same > as -Wno-reorder), and at some point people might demand negative values > for more discriminating checks and floating point values for in-between > choices. > > I think more descriptive would be: > -Wreorder=nonconst and -Wreorder=any > > If someone miraculously cheats Rice's theorem, or wants to propose to get > as close as possible to tell if reordering has a semantic effect as is > feasible to tell in a compiler, you could call it -Wreorder=relevant or > somesuch. > > Thanks. In my humble opinion the -Wreorder=nonconst and -Wreorder=any sounds ok. > I want to know the mem-initializers are in the wrong order ASAP so I can > correct them immediately, not when I change the initializer to a non-constant. ok I understand. Best regards, Daniel
gcc-4.7-20110730 is now available
Snapshot gcc-4.7-20110730 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.7-20110730/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.7 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 176963 You'll find: gcc-4.7-20110730.tar.bz2 Complete GCC MD5=583b5cf3fe7c2ad2a3491f0c53e2e200 SHA1=d31883189b237c84403f9aaf4662148ec8e80870 Diffs from 4.7-20110723 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.7 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Re: patch: don't issue -Wreorder warnings when order doesn't matter
2011/7/29 Daniel Marjamäki : > Hello! > >> Why doesn't it matter in this case but it matters when the initializer >> are non-constant? > > It doesn't matter because the program will behave the same no matter > if the initializations are reordered or not. Logically it will behave > just as the user expects no matter if he expects reordering or not. > > When one initializer is non-constant there might be a dependency > between the two initializations and the wrong order might be a bug. > I would like to silence such warnings also, but I don't want to try to > determine if there is dependencies or not. > > >> If you don't want to fix up your code, just compile it with -Wno-reorder. > > I don't want to use -Wno-reorder , because then I won't see the real > problems. Don't get me wrong, I like this check. > > > When gcc generates noise I think it is better to fix gcc than to fix my code. > > The only reason I can think of to keep this noise is for purely > stylistic reasons. Somebody might think it is a stylistic problem to > initialize members backwards. But then -Wreorder should also warn > about common assignments and I doubt anybody wants that. If the initializer is constant, but the member value that's being initialized has a non-trivial constructor with a side effect, your patch will inhibit the warning but the program will not behave the same as if reordering had not happened. Peter
