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
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
On Mon, Aug 17, 2009 at 9:19 AM, Kenneth Hostekenneth.ho...@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!
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
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
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
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
