Optimisations?
Null Ack
At a compile level some ideas:
* -O3 instead of what appears to be -O2 (noting that mplayer uses -04
which as I understand it is treated by gcc as -O3)
* Use march=native and mtune=native (which again mplayer use)
* Dont know if omit frame pointer and ffast math would be useful or not
Please note that native has made a massive difference in some compiles
Ive done on my system.
I'm not qualified to commend on the code optimisation but perhaps
gains could be made there as well.
Regards
Kevin DeKorte
Hash: SHA1
Personally, I doubt the flags would make any difference to gnome-mplayer
much at all. Since most of the video processing work is actually done by
mplayer so any flags you put on it will make it faster.
Typically gnome-mplayer uses < 1% of the cpu when playing a large video,
with mplayer using 10-20% on my machine.
Feel free to try it, experimentation can't hurt.
Kevin
- --
Get my public GnuPG key from
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x7D0BD5D1
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFIe9cA6w2kMH0L1dERAm5tAJoC0Hne/V+r4zDKM/ysT14KAe4NIQCfQX4M
lRXq6g6UrjOKYUA9+MJGNH0=
=8Q8N
-----END PGP SIGNATURE-----
Null Ack
system I am just able to play some 1920x1080 footage via the command
line so the additional overhead of the GUI really is critical in those
use cases for me. I think also, with mobile internet devices becoming
popular, usage in the 3rd world etcetc having the best possible
performance for your excellent app is important.
I could do with some guidance please (Im not a programmer):
1. Does the code use any math that would be better in ffast-math library?
2. In your view would omit frame pointer help at all?
Ill try compiling with native gcc mode and O4 level like mplayer.
Cheers
Kevin DeKorte
Hash: SHA1
Null Ack wrote:
| Thanks Kevin, I will experiment with it. The reason is that on my
| system I am just able to play some 1920x1080 footage via the command
| line so the additional overhead of the GUI really is critical in those
| use cases for me. I think also, with mobile internet devices becoming
| popular, usage in the 3rd world etcetc having the best possible
| performance for your excellent app is important.
|
| I could do with some guidance please (Im not a programmer):
|
| 1. Does the code use any math that would be better in ffast-math library?
Doubt it, think I have a couple of divisions... nothing fancy like sine
or cosine. And no long calculations, more than a line or so.
| 2. In your view would omit frame pointer help at all?
|
No really sure, but since it is enabled at -O, -O2, -O3, -Os. You are
most likely getting it enabled already,
| Ill try compiling with native gcc mode and O4 level like mplayer.
Let me know if you start getting any crashes with that high of an
optimization level.
Kevin
- --
Get my public GnuPG key from
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x7D0BD5D1
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFIe/hc6w2kMH0L1dERAlqlAJ0btpXAaJloEeD8omvTqP/Zwl+5BwCffsUz
C8uvpM7MdPdjvLMP+88OT0A=
=dhOS
-----END PGP SIGNATURE-----
Null Ack
./configure CFLAGS="-O4 -march=native -mtune=native" CPPFLAGS="-O4
-march=native -mtune=native"
Compiles, runs, did some basic regression tests and all passed. This
is on GCC 4.3.1.
I will ensure to recompile under the standard before submitting any
bugs and I will continue testing this optimised configuration.
cheers
Onur Küçük
On Wed, 16 Jul 2008 08:45:52 +1000
"Null Ack" <nul...@gmail.com> wrote:
...
since you want to go down the scary optimisation road
> I will ensure to recompile under the standard before submitting any
> bugs and I will continue testing this optimised configuration.
Are you sure it is "optimised" when you compile gnome-mplayer with
-O4 ? Try to stay away from placebo effect :)
I believe for gnome-mplayer, since Kevin also said that it is not
doing that much calculations, "-O2 -fomit-frame-pointer -march=native
-mcpu=native" will be more than enough, since the bottleneck with true
HD movies is not gnome-mplayer. If you want to optimise gnome-mplayer,
you should work on optimising the drawing engines and underlying
libraries (GTK family, X etc.), yet this will not give much boost
either.
First thing to optimise is of course MPlayer, usually hand made
configure will be enough. Also choosing the video and audio output
drivers correctly might give a boost depending on your hadware and the
number of sound daemons between your hardware and application. Fiddling
with compile flags of libraries (even glibc), if they were not compiled
with say -mtune=generic, which MPlayer use might also help.
Secondly, optimise your platforms settings. Pushing your video cards
drivers a bit or changing the rendering/AA engine with xorg.conf
options, using a good filesystem suitable for the type of media files
(size etc.), experimenting with kernel scheduler and kernel resource
management stuff (irq controller, and maybe using an irq router, kernel
settings for PCI access like using/not using MSI etc.) are a lot more
important.
Third and last, optimise your hardware. If you can change, how the ATA
disks and optic drives are connected to the motherboard, how many IDE
controllers are enabled and which are used (usually avoiding and
shutting down stupid software raid controllers is a good idea), BIOS
settings for these drives (AHCI etc.), even how you connect your RAM
cards to your motherboard might really surprise you.
I believe you are looking for the answer in the wrong place /
application.
HTH, regards,
--
Onur Küçük Knowledge speaks,
<onur.--.-.pardus.org.tr> but wisdom listens
Null Ack
I realise that -O4 is treated the same as -O3 by GCC. The reason I
used it is because mplayer compiles by default with that setting. The
default mplayer build is optimised out of the box and requires no
further user based optimisations. For example, there's the compile
time optimisations, but also how mplayer defaults the video output
driver to xv and so forth. I noticed Loren Meritt recently introduced
some code optimisations so hopefully that will continue at that end.
I've already optimised the elements below mplayer so that is what is
left when it comes to playing movies with gnome-mplayer.
So far I have found no error with O3 against using O2, so I intend to
keep testing it.
Cheers
Onur Küçük
>
> Thanks for your insights Onur.
>
> I realise that -O4 is treated the same as -O3 by GCC. The reason I
> used it is because mplayer compiles by default with that setting. The
> default mplayer build is optimised out of the box and requires no
> further user based optimisations. For example, there's the compile
> time optimisations, but also how mplayer defaults the video output
> driver to xv and so forth.
Depending on your graphics card, setting video output to gl or gl2, or
if your system has support for it, xvmc might give better performance.
Same goes for audio out, using alsa or oss and skipping sound daemons
might work better too.
Null Ack
is far slower than Xv. I turned off composting but the same situation
occured. Its a pretty poor situation with XVMC only being supported on
MPEG2 with NVIDIA / ATI. MPEG2 is more or less a legacy video codec
now. All my footage is either in AVC or MPEG4-ASP both of which are
far superior to mpeg2. I'd really like IDCT and MC on the GPU for AVC.
Thanks
Null Ack
./configure CFLAGS="-O4 -march=native -mtune=native" CPPFLAGS="-O4
-march=native -mtune=native"
Has been working consistently without a single issue for some moons now :)
I intend to continue using this optimised configure as my default -
falling back to standard for any bug replication.
Kevin on another note, many thanks for your recent enhancements. I
figure that adding positive feedback would spam up the bug system so I
have not posted there. I'm currently unemployed so a donation is
problematic for me but you certainly do have my full gratitude.
Regards