LINUX.ORG.RU

[gentoo] оптимизация сборки mencoder`а

 


0

0

На досуге сравнил время работы сабжа при обработке одного и того-же файла в fedora 12 и gentoo. Arch x86_64.

В федоре MEncoder SVN-r31061-4.4.3 (C) 2000-2010 MPlayer Team В дженту Encoder SVN-r29796-4.4.3 (C) 2000-2009 MPlayer Team

В федоре 
real	10m34.802s
user	10m30.687s
sys	0m2.588s

В дженту
real	11m5.460s
user	11m2.850s
sys	0m2.090s

Т.к. версии сабжа и версии ядер разные соответственно, то особо и не проникся разницей.

Но играя флагами в gentoo и сравнивая результаты, не увидел влияния флагов оптимизации

CFLAGS="-O1 -g0 -march=native -msse4.1 -pipe -ftree-vectorize"
real	11m5.460s
user	11m2.850s
sys	0m2.090s 

CFLAGS="-O2 -g0 -march=native -msse4.1 -pipe -ftree-vectorize"
real	11m20.913s
user	11m18.180s
sys	0m2.280s

CFLAGS="-O2 -march=native -pipe"
real	11m17.272s
user	11m14.860s
sys	0m1.890s
Конвертил xvid в xvid
mencoder "$1" -oac mp3lame -lameopts abr:br=192 -ovc xvid -xvidencopts bitrate=1000:pass=2 -vf pp=de,scale=480:-2 -o "$1"-cowonS9.avi 
CPU intel c2q 9450. Чем объяснить такие странные результаты?

> Но играя флагами в gentoo и сравнивая результаты, не увидел влияния флагов оптимизации

О, Боже! Еще один прозрел!

Igron ★★★★★
()

Во-первых номер федориной ревизии намекает. Во-вторых по умолчанию ебилд мплеера рубит на корню оптимизации, дабы всё работало стабильно.

tensai_cirno ★★★★★
()

и не увидите, mencoder равно как и mplayer, равно как и многие другие медиа-кодеки давно уже не зависят особенно ни от компилятора, ни от флагов, наиболее нагруженные функции написаны на ассемблере напрямую, или используют orc/liboil, тоже с asm

более того, гентушный ebuild отключает например runtime cpu detection (если не написали соответствующий USE) и меняет флаги по умолчанию, которые там выставлены на максимальную производительность -O3 -march=native -ffast-math ( в случае Fedora -march=atom ?) что приводит вас даже к некоторому снижению производительности за счет того что то, что все же написано на C оптимизируется хуже.


вообщем вы сравнивали производительность одного и того-же кода на ассемблере, а не влияние оптимизации.

Sylvia ★★★★★
()

пересобирал в слаке. вот, добавлял к ./configure

--extra-cflags="-O3 -g0 -pipe -march=native -mtune=native -fomit-frame-pointer -funroll-all-loops --param l2-cache-size=256"

выключал CRD. config.h и config.mak проверить также на наличие нужных флагов

sprutos ★★★
()

пересобирал в слаке. добавлял ./configure

--extra-cflags="-O3 -g0 -pipe -march=native -mtune=native -fomit-frame-pointer -funroll-all-loops --param l2-cache-size=256"

выключал RCD. config.h и config.mak проверить также на наличие нужных флагов

sprutos ★★★
()
Ответ на: комментарий от sprutos

--param l2-cache-size=256

можете обьяснить зачем?

во-первых надо смотреть сколько реально l2 кеша на вашем процессоре, на новых уже давно гораздо больший обьем

во-вторых это все равно задается через -march=native, если gcc определил процессор

Sylvia ★★★★★
()
Ответ на: комментарий от Sylvia

>во-первых
мало, да )
cache size : 256 KB

во-вторых

ммм... не задаёца, аднако!
gcc -v -Q -Os -s -pipe -march=native -mtune=native -fomit-frame-pointer -funroll-all-loops -Wall -lpthread -o 0pi pi.c

gcc version 4.3.3 (GCC)
COLLECT_GCC_OPTIONS='-v' '-Q' '-Os' '-s' '-pipe' '-fomit-frame-pointer' '-funroll-all-loops' '-Wall' '-o' '0pi'
/usr/libexec/gcc/i486-slackware-linux/4.3.3/cc1 -v pi.c -march=prescott --param l1-cache-size=16 --param l1-cache-line-size=64 -mtune=prescott -dumpbase pi.c -auxbase pi -Os -Wall -version -fomit-frame-pointer -funroll-all-loops -o - |
/usr/lib/gcc/i486-slackware-linux/4.3.3/../../../../i486-slackware-linux/bin/as -V -Qy -o /tmp/cc6Elczz.o -
GGC heuristics: --param ggc-min-expand=45 --param ggc-min-heapsize=29843
options passed: -v pi.c -march=prescott --param l1-cache-size=16 --param
l1-cache-line-size=64 -mtune=prescott -Os -Wall -fomit-frame-pointer
-funroll-all-loops
options enabled: -falign-loops -fargument-alias -fauto-inc-dec
-fbranch-count-reg -fcaller-saves -fcommon -fcprop-registers
-fcrossjumping -fcse-follow-jumps -fdefer-pop -fdelete-null-pointer-checks
-fearly-inlining -feliminate-unused-debug-types -fexpensive-optimizations
-fforward-propagate -ffunction-cse -fgcse -fgcse-lm
-fguess-branch-probability -fident -fif-conversion -fif-conversion2
-finline-functions -finline-functions-called-once -finline-small-functions
-fipa-pure-const -fipa-reference -fivopts -fkeep-static-consts
-fleading-underscore -fmath-errno -fmerge-constants -fmerge-debug-strings
-fmove-loop-invariants -fomit-frame-pointer -foptimize-register-move
-foptimize-sibling-calls -fpcc-struct-return -fpeephole -fpeephole2
-fregmove -frename-registers -freorder-functions -frerun-cse-after-loop
-fsched-interblock -fsched-spec -fsched-stalled-insns-dep -fsigned-zeros
-fsplit-ivs-in-unroller -fsplit-wide-types -fstrict-aliasing
-fstrict-overflow -fthread-jumps -ftoplevel-reorder -ftrapping-math
-ftree-ccp -ftree-copy-prop -ftree-copyrename -ftree-cselim -ftree-dce
-ftree-dominator-opts -ftree-dse -ftree-fre -ftree-loop-im
-ftree-loop-ivcanon -ftree-loop-optimize -ftree-parallelize-loops=
-ftree-reassoc -ftree-salias -ftree-scev-cprop -ftree-sink -ftree-sra
-ftree-store-ccp -ftree-ter -ftree-vect-loop-version -ftree-vrp
-funit-at-a-time -funroll-all-loops -funroll-loops -fvar-tracking
-fvect-cost-model -fweb -fzero-initialized-in-bss -m32 -m80387
-m96bit-long-double -malign-stringops -mfancy-math-387 -mfp-ret-in-387
-mfused-madd -mglibc -mieee-fp -mmmx -mno-red-zone -mno-sse4 -mpush-args
-msahf -msse -msse2 -msse3 -mtls-direct-seg-refs

зачем?

чтоб было как надо, по-моему мнению ) если не прав, подскажите

sprutos ★★★
()
Ответ на: комментарий от sprutos

>--param l1-cache-size=16 --param l1-cache-line-size=64

все верно, размер кеша GCC не определился , тогда вопросов нет почему этот параметр задается вручную )

Sylvia ★★★★★
()

Собрал gentoo-sources-2.6.34 c processor family core2 с CFLAGS="-O2 -g0 -march=native -msse4.1 -pipe -ftree-vectorize --param l2-cache-size=6144" (равно как и все систему) получил прирост работы менкодера на минуту и glxgears порадовал приростом на ~150 FPS и держится в районе 1295.338 FPS с включенным компизом. xf86-video-ati-6.13.0 [Radeon HD 4670]

macumazan ★★
() автор топика
Ответ на: комментарий от Sylvia

>это все равно задается через -march=
ну дык определит он корку, а кэш у всех разный, у корок-то :)

megabaks ★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.