* GCC 4..4.x speed regression - help? @ 2009-08-16 16:02 ami_stuff 2009-08-16 22:46 ` Bernd Roesch 2009-08-17 0:39 ` ami_stuff 0 siblings, 2 replies; 7+ messages in thread From: ami_stuff @ 2009-08-16 16:02 UTC (permalink / raw) To: gcc 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: GCC 4..4.x speed regression - help? 2009-08-16 16:02 GCC 4..4.x speed regression - help? ami_stuff @ 2009-08-16 22:46 ` Bernd Roesch 2009-08-17 0:39 ` ami_stuff 1 sibling, 0 replies; 7+ messages in thread From: Bernd Roesch @ 2009-08-16 22:46 UTC (permalink / raw) To: gcc 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: GCC 4..4.x speed regression - help? 2009-08-16 16:02 GCC 4..4.x speed regression - help? ami_stuff 2009-08-16 22:46 ` Bernd Roesch @ 2009-08-17 0:39 ` ami_stuff 2009-08-17 6:42 ` Martin Guy 1 sibling, 1 reply; 7+ messages in thread From: ami_stuff @ 2009-08-17 0:39 UTC (permalink / raw) To: ami_stuff; +Cc: gcc 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: GCC 4..4.x speed regression - help? 2009-08-17 0:39 ` ami_stuff @ 2009-08-17 6:42 ` Martin Guy 2009-08-17 8:53 ` Kenneth Hoste 2009-08-17 9:03 ` Paolo Bonzini 0 siblings, 2 replies; 7+ messages in thread From: Martin Guy @ 2009-08-17 6:42 UTC (permalink / raw) To: ami_stuff; +Cc: gcc 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: GCC 4..4.x speed regression - help? 2009-08-17 6:42 ` Martin Guy @ 2009-08-17 8:53 ` Kenneth Hoste 2009-08-17 10:00 ` Richard Guenther 2009-08-17 9:03 ` Paolo Bonzini 1 sibling, 1 reply; 7+ messages in thread From: Kenneth Hoste @ 2009-08-17 8:53 UTC (permalink / raw) To: Martin Guy; +Cc: ami_stuff, gcc 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: GCC 4..4.x speed regression - help? 2009-08-17 8:53 ` Kenneth Hoste @ 2009-08-17 10:00 ` Richard Guenther 0 siblings, 0 replies; 7+ messages in thread From: Richard Guenther @ 2009-08-17 10:00 UTC (permalink / raw) To: Kenneth Hoste; +Cc: Martin Guy, ami_stuff, gcc 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 > > ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: GCC 4..4.x speed regression - help? 2009-08-17 6:42 ` Martin Guy 2009-08-17 8:53 ` Kenneth Hoste @ 2009-08-17 9:03 ` Paolo Bonzini 1 sibling, 0 replies; 7+ messages in thread From: Paolo Bonzini @ 2009-08-17 9:03 UTC (permalink / raw) To: Martin Guy; +Cc: ami_stuff, gcc 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2009-08-17 8:53 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2009-08-16 16:02 GCC 4..4.x speed regression - help? ami_stuff 2009-08-16 22:46 ` Bernd Roesch 2009-08-17 0:39 ` ami_stuff 2009-08-17 6:42 ` Martin Guy 2009-08-17 8:53 ` Kenneth Hoste 2009-08-17 10:00 ` Richard Guenther 2009-08-17 9:03 ` Paolo Bonzini
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).