[MPlayer-dev-eng] Re: Compile options

[Trent Piepho]

On Wed, 20 Sep 2006, Andrew Savchenko wrote:
> I've made some tests for 3 movie types: H264 HD
> (http://images.apple.com/movies/wb/the_fountain/the_fountain-tsr_h480p.mov),
> x264 and mpeg4; and for 4 sets of compile options: general -O4 option,

Is there a sample to download for the mpeg4 test?

> There are my results, mplayer-dev-SVN-r19909-4.0.2 was used:
> ==========================================================
> Results for H264 HD:
> ==> General -O4 build:
>
> vc: (4.724 \pm 0.009)s
> vo: (25.117 \pm 0.013)s
> user: 0m(19.842 \pm 0.054)s

I'm not sure I follow the syntax here.  Does "\pm 0.009" mean that the
sample standard deviation is .009 seconds, or the sample variance?  Or is
it the variance/standard deviation of the sample mean?

You can not properly compare the results with just the mean and variance.
You need to also know the number of samples to know how many degrees of
freedom there are in the t distribution.

If you are trying to compare multiple groups at once, then you might want
to try using ANOVA instead of multiple t tests.  In that case, you also
need to know the number of samples in each group.

> As you can see, for H264 HD -O4 general build, -fno-inline-functions for
> dsputil_mmx.o is indeed the fastest, also it is the fastest for an
> ordinary h264. But for mpeg4 is is slower than -O4.
>
> Thereby there is no compile option which provides the fastest code for
> decoding arbitrary type of movie. When we make optimizations for h264,
> we simultaneously make mpeg4 playback slower and vice versa.

It seems like there are some functions which h264 inlines that cause the
code size to grow very large, effecting the cache miss rate enough to make
inlining slower.  Why doesn't this also make mpeg4 slower?  I can think
of a two reasons:
1. Most functions get faster with inlining, but some get slower.  mpeg4
   either doesn't use, or uses less, the functions which get slower.  Or h264
   doesn't use, or uses less, the functions which get faster.
2. mpeg4 has a smaller code size elsewhere, and so it's working set still
   fits in the cache with the larger functions.  h264's working set size is
   larger, and so inlining has an overall negative impact.

If the first reason is the cause, then attribute((noinline)) could be added
to the functions which get slower with inlining.  Comparing the code size
of each exported function of dsputil_mmx.c with and without
-finline-functions will find which functions get much larger.  Then one
must find what functions those functions are inlining that causes them to
get larger and noinline them.

One could also use profiling, and try to find which functions get slower
with inlining, then find what functions they call that should be noinlined.

There are also some gcc parameters that can be set to fine-tune inlining.
large-function-growth looks like one that holds promise.