GCC 4..4.x speed regression - help?

GCC 4..4.x speed regression - help?

[ami_stuff]

Hi,

I found out that GCC 4.4.x build of minigzip from zlib package is a lot slower compared to GCC 3.4.0 build.
Maybe someone can compile minigzip for his system with GCC 3.4.x and GCC 4.4.x and compare time of compression
with bigger file? This way we would know if this regression only happens on the m68k GCC or maybe on other
platforms too.

I really don't like regressions like this :/

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40454

Regards

Re: GCC 4..4.x speed regression - help?

[Bernd Roesch]

please correct the Bugreport 40454 with the values of gcc 4.1.2 4.2.5.

it seem 4.1.2 reach near same speed as 3.4.0 but all later gcc are
slower in some programs.

this can also see on ffmpeg. also on X86 ffmpeg see here it is see.

what is change after 4.1.2 that can cause slower executable speed ?

here can also see on ffmpeg X86 that GCC compiler upto 4.1.2 get near same
speed, then on 4.2.4 it get suddenly slower.

http://multimedia.cx/eggs/intel-beats-up-gcc/

On 16.08.09, you wrote:

> Hi,
> 
> I found out that GCC 4.4.x build of minigzip from zlib package is a lot
> slower compared to GCC 3.4.0 build. Maybe someone can compile minigzip for
> his system with GCC 3.4.x and GCC 4.4.x and compare time of compression
> with bigger file? This way we would know if this regression only happens
> on the m68k GCC or maybe on other platforms too.
> 
> I really don't like regressions like this :/
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40454
> 
> Regards
> 
Regards

Re: GCC 4..4.x speed regression - help?

[ami_stuff]

Hi,

The problematic source code is deflate.c from libz.

CFLAGS=-O3 -DUSE_MMAP -m68060 -fomit-frame-pointer

When I compile all source code with GCC 4.4.1, I get slow minigzip binary.

When I compile all source code with GCC 4.4.1 except deflate.c (this one I
compile with GCC 3.4.0), I get minigzip binary with normal speed.

Regards

Re: GCC 4..4.x speed regression - help?

[Martin Guy]

Yes, GCC is bigger and slower and for several architectures generates
bigger, slower code with every release, though saying so won't make
you very popular on this list! :)

One theory is that there are now so many different optimization passes
(and, worse, clever case-specific hacks hidden in the backends) that
the interaction between the lot of them is now chaotic. Selecting
optimization flags by hand is no longer humanly possible.

There is a project to untangle the mess: Grigori Fursin's MILEPOST GCC
at http://ctuning.org/wiki/index.php/CTools:MilepostGCC - an AI-based
attempt to autmatically select combinations of GCC optimization flags
according to their measured effectiveness and a profile of you source
code's characteristics. The idea is fairly repulsive but effective -
it reports major speed gains of the order of twice as fast compared to
the standard "fastest" -O options, and there is  Google Summer of Code
2009 project based on this work.

It seems to me that much over-hacked software lives a life cycle much
like the human one: infancy, adolescence, adulthood, middle-age (spot
the spread!) and ultimately old age and senility, exhibiting
characteristics at each stage akin to the mental faculties of a
person.

If you're serious about speed, you could try MILEPOST GCC, or try the
current up-and-coming "adolescent" open source compiler, LLVM at
llvm.org

    M

Re: GCC 4..4.x speed regression - help?

[Kenneth Hoste]

On Aug 16, 2009, at 18:02 , Martin Guy wrote:

> Yes, GCC is bigger and slower and for several architectures generates
> bigger, slower code with every release, though saying so won't make
> you very popular on this list! :)
>
> One theory is that there are now so many different optimization passes
> (and, worse, clever case-specific hacks hidden in the backends) that
> the interaction between the lot of them is now chaotic. Selecting
> optimization flags by hand is no longer humanly possible.

That, and the fact that GCC supports so many (quite different) targets
while keeping the set of optimization passes roughly equal across
these targets probably also doesn't help...

I'm aware there are (good) reasons to try and keep it that way, but it  
seems
the reasons against it are getting stronger.

Just my 2 cents.

Kenneth

PS: There's MILEPOST, but there are other projects too. Check out Acovea
(http://www.coyotegulch.com/products/acovea) and my very own
pet COLE (http://users.elis.ugent.be/~kehoste/, see the publications  
section).

-- 

Kenneth Hoste
Paris research group - ELIS - Ghent University, Belgium
email: kenneth.hoste@elis.ugent.be
website: http://www.elis.ugent.be/~kehoste
blog: http://boegel.kejo.be

Re: GCC 4..4.x speed regression - help?

[Paolo Bonzini]

On 08/16/2009 06:02 PM, Martin Guy wrote:
> Yes, GCC is bigger and slower and for several architectures generates
> bigger, slower code with every release, though saying so won't make
> you very popular on this list! :)

But surprise, if you report a bug, chances are it will be fixed 
(especially for something as well known as gzip).

And it is actually useless to post on the mailing list, since the bug is 
there for interested people anyway.

Paolo

Re: GCC 4..4.x speed regression - help?

[Richard Guenther]

On Mon, Aug 17, 2009 at 9:19 AM, Kenneth Hoste<kenneth.hoste@ugent.be> wrote:
>
> On Aug 16, 2009, at 18:02 , Martin Guy wrote:
>
>> Yes, GCC is bigger and slower and for several architectures generates
>> bigger, slower code with every release, though saying so won't make
>> you very popular on this list! :)
>>
>> One theory is that there are now so many different optimization passes
>> (and, worse, clever case-specific hacks hidden in the backends) that
>> the interaction between the lot of them is now chaotic. Selecting
>> optimization flags by hand is no longer humanly possible.
>
> That, and the fact that GCC supports so many (quite different) targets
> while keeping the set of optimization passes roughly equal across
> these targets probably also doesn't help...
>
> I'm aware there are (good) reasons to try and keep it that way, but it seems
> the reasons against it are getting stronger.

The main reason for it is scalability of maintainance - while I bet it
would work well for popular architectures like x86 or ppc (hey, but
those don't exhibit the problems anyway...) less popular architectures
would even less benefit from the bugfixing in general code.

Richard.

>
> Just my 2 cents.
>
> Kenneth
>
> PS: There's MILEPOST, but there are other projects too. Check out Acovea
> (http://www.coyotegulch.com/products/acovea) and my very own
> pet COLE (http://users.elis.ugent.be/~kehoste/, see the publications
> section).
>
> --
>
> Kenneth Hoste
> Paris research group - ELIS - Ghent University, Belgium
> email: kenneth.hoste@elis.ugent.be
> website: http://www.elis.ugent.be/~kehoste
> blog: http://boegel.kejo.be
>
>