[Ffmpeg-devel] 2.95?

[Rich Felker]

On Thu, Jul 13, 2006 at 10:53:47PM +0100, M?ns Rullg?rd wrote:
> Vladimir Mosgalin <mosgalin at VM10124.spb.edu> writes:
> 
> > Hi M?ns Rullg?rd!
> >
> >  On 2006.07.13 at 21:29:38 +0100, M?ns Rullg?rd wrote next:
> >
> >> > Rich Felker wrote:
> >> >> Yes, gcc devs want to keep us from discovering and using the
> >> >> infinitely superior gcc 2.95 !! :)
> >> >
> >> > Loathe as I am to admit it, you might be onto something here, at least
> >> > for compilation speed. gcc 2.95 compiles the tree in 15 minutes. 3.4.6
> >> > takes 21 minutes. ~30 minutes for 4.1.1.
> 
> BTW, you should get a faster computer.  My lowly pentium4 2.8 does a
> full ffmpeg build with gcc 3.4.6 in just under 6 minutes.

So does my K6-III+/500.... You should get a faster compiler. :)

> >> In theory, the compiler could be spending that extra time optimizing
> >> the code.  Were that the case, I'd happily trade a little compilation
> >> time for faster execution.  Sadly, I'm afraid this is not the case
> >> here.
> >> 
> >
> > Haven't you read benchmarks in mplayer-dev list? It IS the case here.
> > Binary compiled with gcc4 is faster than the one compiled with gcc3,
> > which is faster than gcc295 binary.
> 
> That's good news.  I know lots of development effort on gcc has gone
> into c++ support, sometimes at the expense of plain c performance
> (both in compilation time and code speed).  GCC 3.0 was certainly
> nothing to be proud of.

The call frame/exception handling/itanium abi stuff is an abomination,
and it affects C users in bad ways too. For instance, libgcc_s.so gets
linked to the system libc (because of this crap), which is hell for
uClibc users since they can't build non-glibc binaries without
building a whole new gcc toolchain with that nonsense fixed..

Rich