[MPlayer-dev-eng] Re: Compile options

[Andrew Savchenko]

On 18 Sep 2006 07:06, Trent Piepho wrote:

> > Can somebody else confirm one or the other result?
>
> mplayer svn compiled with:
> -fno-PIC -march=athlon-xp -mtune=athlon-xp -ffast-math
> -fomit-frame-pointer
>
> and -O2 or -O4.  I used the apple Serenity 1080p trailer, with codec
> ffh264.  mplayer options were -quiet -benchmark -vo null -nosound
>
> Results:
<skip>
> The 95 percent confidence interval tells us that we can be 95%
> certain that O2 is 3.575077 seconds or more faster than O4.

Thanks for reliable results. It is interesting now to figure out why our 
results are differ.

On 18 Sep 2006 12:48, Carl Eugen Hoyos wrote:
> > Moreover, I've make h264 short film (2 minutes) as I promised
> > earlier. Your results are uncormfimed again. On my system playback
> > of h264 movie (using [ffh264] vfm: ffmpeg (FFmpeg H.264)) is
> > clearly faster with -O4 than with -O2.
>
> This is a link to the smallest HD trailer I found on Apples homepage
> (9MB):
> http://images.apple.com/movies/wb/the_fountain/the_fountain-tsr_h480p
>.mov (You can get it with wget)

Thank for the links. Here is my results (options are applied to all 
build):

for -O4:
VC:   (4.802 \pm 0.003)s
VO: (25.140 \pm 0.014)s
user   (0m19.94s \pm 0m0.06s)

for -O2:
VC:   (4.758 \pm 0.006)s
VO: (25.220 \pm 0.018)s
user   (0m19.98s \pm 0m0.05s)

Difference O2 - O4:
VC: (-0.044 \pm 0.007)s
VO:  (0.080 \pm 0.023)s
user (0m0.04s \pm 0.08)s

Thus on trailer you provided vc is slightly faster, vo is slightly 
slower and summary is unchanged within errors. But be awared, that VC 
is _slower_ on other types of movies in this case (mpeg4 for example). 
So this prolem needs further investigation.

Well, maybe in will be usefull to add -fno-inline-fuctions to 
dsputil_mmx.c only. I'll test this on different types of movies and 
will report later.

On 18 Sep 2006, 14:05 Michael Niedermayer wrote:
> * check that _all_ compiler flags are equal between both testers

They seems to be the same since we are using both 32-bit AthlonXP

> * use the same video and same svn version of mplayer and libavcodec
>   ideally both of you should get a fresh checkout of mplayer&lavc

It's not a problem.

> * check that no shared lavc is used

Of cause no shared lavc is used -- this will only slower things down.

> * check that the compiler versions are identical
> * both should get a official clean gcc release and comile them
> yourself to avoid possible messup by the distributions gcc maintainer

It is not easy to do without system mess up in my case.

On 19 Sep 2006 06:08, Carl Eugen Hoyos wrote:
> > this is getting quite interresting, id suggest the following if
> > theres some interrest in figuring out where these differences come
> > from * check that _all_ compiler flags are equal between both
> > testers * use the same video and same svn version of mplayer and
> > libavcodec ideally both of you should get a fresh checkout of
> > mplayer&lavc
>
> I only tested H264 HD clips (Apple movie trailers), while Andrew
> tested MPEG4 and x264 files that do not seem to be affected by -O2
> (=-fno-inline-functions).

Yes, VC is possibly not affected, but mplayer in general is slower for 
mpeg4 with -O2 rather than with -O4. You can't optimize code for one 
type of movie by the cost of slowing down athoter one. As I've metioned 
above, maybe usage of -fno-inline-functions only for dsputil_mmx.c will 
do a trick.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20060919/a7160e67/attachment.pgp>