[Ffmpeg-cvslog] CVS: ffmpeg/libavcodec/i386 h264dsp_mmx.c, 1.15, 1.16

[Rich Felker]

On Wed, Mar 08, 2006 at 07:34:03PM +0100, Diego Biurrun wrote:
> On Wed, Mar 08, 2006 at 11:34:31AM -0500, Rich Felker wrote:
> > On Wed, Mar 08, 2006 at 11:39:16AM +0100, Guillaume POIRIER wrote:
> > > 
> > > On 3/8/06, Rich Felker <dalias at aerifal.cx> wrote:
> > > > On Sat, Mar 04, 2006 at 11:31:47PM +0200, Ismail Donmez wrote:
> > > > > Maybe off topic but linux kernel recently dropped support for gcc < 3.2 , it
> > > > > might be worth to reconsider gcc 2.95 support in ffmpeg too.
> > > >
> > > > Yes and as we all know Linux sucks...
> > > >
> > > > > P.S: No flamewar intended
> > > >
> > > > Bad idea suggesting this then... :)
> > > 
> > > Somehow, I see it logical to have someone having an old distro (let's
> > > say RH 7.0) and wanting to build a recent userland app, like FFmpeg
> > > from CVS... On the contrary, having an old distro and upgrading to
> > > latest 2.6 seems quite a more invasive task as it requires to upgrade
> > > the a fair deal of core apps which gravitates around the kernel.
> > > So IMHO it only sound logical that the kernel dev folks drop old
> > > compilers, and userland dev folks keeping compatibility with old
> > > compilers which haven't gone dodo yet.
> > 
> > The issue at hand isn't what's common case with distros, but whether
> > gcc3/4 is better or worse. For many users it's worse. If you compile a
> > lot of software from source, the slowness of gcc3/4 is extremely bad.
> > With gcc3, the performance gains in the resulting binaries were
> > marginal or often even negative (i.e. worse performance than 2.95). I
> > hear gcc4 has cleaned up this regression to some extent, but they need
> > to improve compiletime performance before it's viable for everyone to
> > use.
> 
> I ran some benchmarks with MPlayer compiled with different versions of
> gcc ages ago on my K6-III.  The result was that gcc 3.x produced smaller
> binaries than 2.95.3.

This may have been because gcc3/4 sometimes refuse to inline functions
even when you tell them to, unless you use attribute(always_inline)...
On the other hand, my libc reportedly dropped from 100k to 85k when
compiled with gcc4 instead of 2.95, so I'm willing to believe there's
a legitimate size improvement too.

> gcc 3.x took 40-80% longer to compile.  The
> binaries produced by gcc 3.4 were about 5% faster than 2.95, the other
> gcc versions were slower.

My last detailed testing was with gcc 3.1, and MPlayer was 10% slower
than with 2.95. I'm willing to believe the situation has improved
since then, but don't feel like dealing with gcc3/4 until at least
after my system overhaul, especially due to libgcc versioning
issues... (my new system won't even have libgcc so it's a non-issue :).

> Note that this only applies to x86.  gcc 2.95 is horrible on at least
> PPC.

Yes. For better or worse, tho, PPC has no future..

Rich