[MPlayer-dev-eng] quick gcc version comparisons

Moritz Bunkus moritz at bunkus.org
Wed Apr 28 21:46:56 CEST 2004


Hi,

1) Introduction

this is a short comparison between four different gcc versions:
2.95.4, 3.2.3, 3.3.3 and 3.4. The first three are from Debian's
unstable, the fourth from Debian's experimental tree. The sources used
were MPlayer 1.0pre4. The computer's a Duron at 1GHz with 512MB PC100
SDRAM and some other stuff in case you're wondering. In each case I've
simply run

CC=gcc-x.y.z ./configure

without any additional parameters.

I've also diff'ed the output that each configure run spits out. The
ones for 3.x.y are nearly identical safe for the gcc version number,
of course ;) The log for 2.95 also shows different optimizations, but
that's to be expected, too. Most important: the features that will be
compiled into the binaries are the same for each.

2) Compilation speed

Everyone knows that 2.95 is FAST and that the 3.x series
is... well... slow as hell. But 3.4 is supposed to be better in this
regard, so I'm curious how much better it is.

Here are the results:

2.95.4 |  7m18s
3.2.3  | 12m01s
3.3.3  | 11m54s
3.4    | 10m40s

Wow. 3.2.3 and 3.3.3 just suck. 3.4 is definitely an improvement, but
they're still FAR away from the 'good old days'.

3) Binary size

A very interesting topic. I've stripped the mplayer and mencoder
binaries. Here's the results:

         |  2.95.4 |   3.2.3 |   3.3.3 |     3.4
---------+---------+---------+---------+--------
mplayer  | 4714368 | 4820068 | 4792844 | 4460580
mencoder | 4508836 | 4598868 | 4573360 | 4249484

I've expected 3.2.3 and 3.3.3 to be bigger than 2.95.4, and to be
honest, I don't think that 100kb is anything to be ashamed of for
binaries of this size. What really surprised my are the results for
3.4. They're definitely smaller than what I'd have expected...

4) Benchmarks

I've run the benchmarks this way:

for i in $(seq 1 10); do 
  for ver in 2.95 3.2 3.3 3.4; do
    mplayer -vo null -nosound -v -benchmark -frames 2000 file1.avi &> res-f1-$ver-$i.txt
    mplayer -vo null -nosound -v -benchmark -frames 20000 file2.m2v &> res-f2-$ver-$i.txt
  done
done

and then run a Perl script that calculates the aerage for the last
value in the BECHMARKs value. Here are the results:

       |  file 1 |  file 2 |  file 3
-------+---------+---------+--------
2.95.4 | 10.5157 |  6.1265 | 10.4900
3.2.3  | 10.1548 |  5.6842 | 10.2801
3.3.3  | 10.1550 |  6.3768 | 10.4224
3.4    | 10.1422 |  5.7463 | 10.1216


File 1 is an AVI with XviD (640x368), file 2 is a SVCD, File 3 is an
AVI with XviD (640x352).

So what could these results mean?

1) The benchmark command is b0rked, and the results can be sent right
   to /dev/null.
2) The results are OK and gcc 3.4 simply optimizes better than the
   others.
3) I have no clue what to make of them ;)

Mosu

-- 
If Darl McBride was in charge, he'd probably make marriage
unconstitutional too, since clearly it de-emphasizes the commercial
nature of normal human interaction, and probably is a major impediment
to the commercial growth of prostitution. - Linus Torvalds




More information about the MPlayer-dev-eng mailing list