Dotaz: Jak vyždímat z procesoru maximum?

[hufhendr]

Zdravím,

potřeboval bych nějak přinutit systém, aby jeden program (mencoder) dostával mnohem více výkonu procesoru. V jádře mám (snad dobře) zakompilovanou podporu pro SMP i Real Time Clock, mplayer mám s podporou RTC, zkoušel jsem zvyšovat prioritu přes renice -20 PID, nastavil jsem obě jádra natvrdo na max 1.8GHz, experimentoval jsem s příkazem chrt, ale pořád je to málo. Přitom ale vidím, že nepočítají obě jádra na plný výkon a dokonce jsem zahlédl, že mi ten proces občas usíná.
Nechce se mi kupovat nový procesor a věřím, že existuje způsob jak ten proces přibít natrvalo na 98%, jen už nevím jak dál.

Předem děkuji za každou radu.

Odpovědi

[jirkamailto]

 No je vubec otazka, zdali program ma podporu pro SMP, umi vyuzivat vice jader. Pokud ano, tak se podivejte, jestli v softwaru mate zapnutou tuto volbu.

[hufhendr]

Díky, ačkoli mám přes globální USE nastavenou podporu SMP pro všechny, konkrétně u mplayeru není ani zapnutá ani vypnutá, není tam překvapivě vůbec. To mě nenapadlo. Při enkódování videa je mplayer spuštěný hned 3x. Nevím ale, co konkrétně který z nich dělá, 2 z nich berou z procesoru mnohem méně.
Mplayer-smp v portage nevidím, byla by cesta přilepit tento mplayer nějak přes afinitu na 1. jádro a vnutit mu nejvyšší prioritu?

 

[rastos]

Přitom ale vidím, že nepočítají obě jádra na plný výkon

Môžeš to nejak kvantifikovať? Ako to zisťuješ a čo vidíš? Nemôže to byť tým, že mencoder čaká na I/O? Skúšal si ionice? Skúšal si okresať iné služby bežiace na tom systéme?

Ja práve bežím mencoder na jedno-processorovom systéme a load je konštantne na 100%.

[hufhendr]

Tak tohle mě vůbec nenapadlo, možné to je. Disk nijak zvlášť nebliká, vypadá v pohodě, ale je fakt, že už kdysi dávno mě překvapil nebezpečně špatnými hodnotami při čtení i zápisu.
Vidím to jednoduše přes gnome-system-monitor nebo htop, vždy je jedno jádro zatížené víc, pak se třeba po čase prohodí, obě naplno nejedou nikdy, ale jedno si na 100% sáhne - nedrží se tam ale konstantně pořád jako třeba při rekompilaci systému.
Ionice zkusím, kolem toho čekání na data by mohl být problém, jak to mohu prozkoumat a odladit víc?

[cronin]

Prva otazka je, ci samotny program je napisany tak, aby vedel svoju pracu rozdelit na viacero procesorov, ako bolo naznacene vyssie.

Druhy problem je, ze pri spracovavani vacsieho mnozstva udajov - co zmienene programy zjavne robia - skor ci neskor dojde k situacii, ze je potrebne tieto udaje nacitat z pamate, vyprazdnit cache pamat pre nove polozky, zmenit zaznamy v TLB a pod. Vsetky tieto operacie su z pohladu procesora velmi pomale a pocas ich vykonavania jednoducho nema co robit. Optimalizacia pozostava v takych upravach aplikacie a prostredia, aby k tymto preruseniem dochadzalo co mozno najzriedkavejsie. Upravy a optimalizacie su mozne na viacerych miestach:

- Prekladac moze na zaklade urcitych algoritmov ci heuristik robit mikrooptimalizacie za ucelom lepsieho vyuzitia registrov procesora a cache pamati ci pouzivania prednacitavania udajov. Ako "pouzivatel" mozes skusit prelozit konkretnu aplikaciu (alebo kniznicu vykonavajucu "kriticky" algoritmus) s optimalizacnou volbou -Os namiesto obligatneho -O2. Sice to vypne niektore optimalizacie, ale zmensi to kod, a teda viacej kodu sa zmesti do cache pamate, a teda sa nemusi citat z pomalej hlavnej pamate.

- Operacny system moze optimalizovat vyuzitie prekladovej tabulky TLB. V poslednych verziach FreeBSD sa za tymto ucelom implementovali tzv. "superpages", t.j. pamatove stranky premenlivej velkosti, potencialne ovela vacsie ako bezna stranka. Tym moze jeden TLB zaznam adresovat viac pamate a teda aj cela TLB prekladova tabulka moze adresovat viac pamate naraz. Informaciou o superpages v Linuxe nemozem sluzit. Ako "pouzivatel" mozes patrat, ci takato funkcia (alebo podobne funkcie) sa v jadre nachadza, a ak ano, skusit ju pripadne zapnut, ak je vypnuta. Dobry napad je aj upgradovat na novsie jadro; nedavno sa v jadernych novinach objavila pekna sprava o tom, ako drobne mikrooptimalizacie v kode spravy pamate vykonostne pomohli aj mnohym inym inym oblastiam.

- Nakoniec mozno pouzit upravy samotneho algoritmu tak, aby lepsie vyuzivali cache pamat. Zvycajne sa jedna o velmi neintuitivne algoritmy riesenia problemov; hladaj "cache oblivious algorithm", ak si programator, rozhodne odporucam niektore si len tak pre ilustraciu vyskusat. Ako "pouzivatel" nemozes patrne tento druh optimalizacie pouzit.

Nakoniec len dodam, ze velkym spomalovacom su IO operacie. Stretol som sa s programom, ktory vytvaral znacne mnozstvo docasnych suborov. Zatial co jeho beh nad normalnym diskom trval cca 2 minuty, presunutim na memory disk sa doba skratila pod 30 sekund.

[hufhendr]

Našel jsem v jednom diskusním fóru k mplayeru, že podporu SMP nemá a ani se neplánuje, protože nejužším hrdlem je stejně sběrnice a navíc by to bylo moc pracné. Každopádně se to nějak dělí na 3 stejné procesy.

Programátor nejsem, spíš normální uživatel, používám 64bit jádro, SLAB allocator; mohlo by pomoci přejít na SLUB? K těm superpages, včera jsem zrovna náhodou překládal jádro 2.6.30 a všiml jsem si volby CONFIG_DEFAULT_MMAP_MIN_ADDR (65536). Může to být ono?

Mplayer jsem zkusil přeložit znovu CFLAGS="-march=core2 -Os -pipe" emerge mplayer, ale asi to nebude dobře, protože při kompilaci jsem zahlédl -O4 -march=native. Stejně ani s tímto novým mplayerem na 100% nedosáhnu a přitom nestíhá.

Možná to opravdu bude zakleté v disku, rád bych to hodil do RAM, jenže 8GB je už docela dost.

 

[petr_p]

používám 64bit jádro, SLAB allocator; mohlo by pomoci přejít na SLUB?

To je alokátor jederné paměti. Ta s počítáním mplayeru nemá nic společného.

CONFIG_DEFAULT_MMAP_MIN_ADDR

Hodí se taky přečíst nápovědu ;) CONFIG_DEFAULT_MMAP_MIN_ADDR omezuje adresu, kam uživatelský proces mmapuje paměť, zespoda. Je to preventivní bezpečnostní opatření (které se začalo používat jako reakce na poslední nalezenou bezpečnostní chybu v Linuxu). Opět nemá vliv na výkon. V praxi akorát tak zabije virtuální stroj, který se snaží emulovat bootovací režim i386 v86.

CFLAGS="-march=core2 -Os -pipe"

Co vás lidi furt k optimalizaci na velikost? Vždyť moderní hyperrychlé x86 procesory se naopak vyznačují monstrózní keší (jeden z důvodů obrovského příkonu).

při kompilaci jsem zahlédl -O4 -march=native

USE=custom-cpuopts

[hufhendr]

Zkusil jsem i ten SLUB alokátor, ale ačkoli můj subjektivní pocit byl, že se to mírně zlepšilo, stejně to nestačilo.

CONFIG_DEFAULT_MMAP_MIN_ADDR: už jsem nevěděl kudy kam, zkusil jsem to :) A stejně i když už mám přeložené jádro 2.6.30, nemohu to využít, protože mě hrozně zlobí ovladače grafiky Intel. Nechtělo se mi to řešit, takže jsem na 2.6.28

CFLAGS="-march=core2 -Os -pipe" stejně nepomohlo. Snažil jsem se mít ten systém naladěný co nejlépe už od začátku a tak nepomohlo vlastně skoro nic, co jsem zkoušel. Přesto má příběh šťastný konec ...

[M. Lox]

A jaké používáš volby při kódování? Třeba x264enc je vícevláknový, ale filtry (-vf) nejsou, takže pokud např. používáš deinterlace filtr a kóduješ do H.264, tak chvíli poběží obě jádra, chvíli jenom jedno, podle toho, ve které části zpracování videa se mencoder zrovna nachází.

[hufhendr]

No vlastně já to kóduji obráceně, z H.264 do Mpeg2, ale moc šancí nějak to ovlivnit nemám - co jsem se díval, tak snad jen keyint, vqscale a vqmin, ostatní si poručí server. Pro mne je důležité, aby to běželo opravdu realtime, protože v obýváku je televize a pomalý výpočet způsobuje záseky.
Tohle jsem odchytl, běží to 3x, 1 bere 80%CPU, další dva kolem 12:

mencoder -ss 0 -quiet /data/video/Terminator/The.Terminator.1984.1080p.BluRay.x264-hV.mkv -quiet -quiet -oac copy -of mpeg -lavfopts format=asf -mpegopts format=mpeg2:muxrate=500000:vbuf_size=1194:abuf_size=64 -ovc lavc -channels 2 -lavdopts debug=0:threads=2 -lavcopts autoaspect=1:vcodec=mpeg2video:acodec=ac3:abitrate=384:threads=2:keyint=1:vqscale=1:vqmin=2 -subcp cp1250 -subfont-text-scale 3 -subfont-outline 1 -subfont-blur 3 -subpos 98 -aid 0 -sid 0 -quiet -quiet -ofps 24000/1001 -quiet -quiet -af lavcresample=48000 -srate 48000 -o /tmp/javaps3media/mencoder1249479680448

 

[dustin]

A není nějaká možnost ten původní formát rovnou dekódovat na obrazová data (digitální nebo analog), aby se nemuselo přes mpeg2?

[hufhendr]

Bohužel ne, počítač funguje jako DLNA server.
V době psaní článku jsem ale neměl žádný skutečně HD film a ani FullHD televizi.

[dustin]

Aha, díky za zajímavý článek a nakopnutí poučné diskuse pod ním.

[msaft]

Imho na konverzi h264 --> mpeg2 je neslozitejsi dekodovani h264. To je ale skutecne jednovlaknova vec. Pro vetsi vykon bud zakompilovat vicevlaknovy ffmpeg-mt (experimentalni?) nebo dekodovat s hw podporou (nvidia vdpau).

[hufhendr]

Díky moc, vlastně to tu naznačovali skoro všichni. Ten ffmpeg-mt byl skvělý tip!

[hufhendr]

Příloha:

• performance_x264.png (63892 bytů)

Ještě jsem si všiml, že jde přiložit obrázek, takže posílám screenshot když opravdu nestíhá. Všechna menší (i když veliká) videa šla v pohodě, ale s rozlišením 1920x1040 nastal problém. Odhaduji, že by mi stačilo vyždímat z počítače celkově tak 10% navíc a bude to OK.

[cronin]

Staci 10%? Overclocking!

Pozeram, ze zataz sa symetricky prepina medzi jadrami, tak mi napada: ten procesor ma dve jadra, kolko ma ale FPU? Typujem, ze len jednu. Ak je algoritmus zalozeny na praci s pohyblivou radovou ciarkou, moze to byt zavazne obmedzenie. O aky procesor sa vlastne jedna? Ak ma HT, odporucam skusit vypnut; zvycajne robi viac skody, ako osohu.

[hufhendr]

Je to E4300 a z výpisu vypadá, že má každé jádro své FPU.

Jinak je to z této sestavy, jen je doplněná na 4GB RAM.

[Brud]

Ten system evidetne travi vetsinu casu v systemu ...

[Brud]

Pokud to mam jeste upresnit, tak pokud je to dvoujaderny procesor, tak vetsinu casu ten system travi v operacich, ktere jsou mimo user.

Tudiz vetsinu veci travi ve vecech co ty nedokazes ovlivnit, nebot to ten system potrebuje. A soude dle toho obrazku, at tam delas cokoliv tak to bezi na prave pulku jader co mas, zbytek to travi ve vecech co jsou tobe sumak a nedokazes ovlivnit.

[hufhendr]

Podle výpisů zatížení to na mě působilo, že krom toho encódování skoro vůbec nic nedělá. Hrál jsem si všemožně s renice -20 PID, chrt -p PID, ionice -c 1 -p PID i taskset -p 01 PID a nakonec jsem došel ke stejnému závěru, že s tím nic nenadělám. Ale i tohle pomohlo...

[Brud]

Ci finalne, ta aplikace neumi vyzit dvou jader ...

[Brud]

Jeste by byla zajiam diskova zatez celkove statistiky sytemu jako iostat atd...

To vypad sice ze to tam naneco ceka, ale tam bude primarni problem, ze to neumi pouzit vic jak jedno jadro ...

[hufhendr]

# iostat 
Linux 2.6.28-gentoo-r5 (dx2300) 	6.8.2009 	_x86_64_	(2 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          15,33    0,01    0,71    2,13    0,00   81,82

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda               5,20       243,78        19,79    9743355     791106

# sar 1 5
Linux 2.6.28-gentoo-r5 (dx2300) 	6.8.2009 	_x86_64_	(2 CPU)

07:18:37        CPU     %user     %nice   %system   %iowait    %steal     %idle
07:18:38        all     53,23      0,00      0,50      1,99      0,00     44,28
07:18:39        all     57,21      0,00      1,49      1,49      0,00     39,80
07:18:40        all     59,41      0,00      0,50      1,49      0,00     38,61
07:18:41        all     53,23      0,00      1,99      1,49      0,00     43,28
07:18:42        all     56,28      0,00      1,01      1,01      0,00     41,71
Average:        all     55,88      0,00      1,10      1,49      0,00     41,53

[AraxoN]

mencoder skrátka a jednoducho nie je multithreadový pre tú úlohu, ktorú ty po ňom chceš. Jeden mencoder vyťaží jedno jadro. Nič viac s tým nenarobíš. Jedine, že by si vedel prácu rozdeliť na nezávislé časti a tie časti potom spustil v dvoch nezávislých mencoder-och.

[chinook]

To znamena, pokud mam 2 procesory po 4 jadrech, tak kdybych napr. spustil 8x encoder na 8 videi, tak pojede vsech 8 jader na 100%?

[AraxoN]

Áno, malo by - ak disk bude stíhať čítať a zapisovať toľko údajov.

[hufhendr]

Tomu bych docela rozuměl, ale proč to jedno jádro nevytíží na 100% ?
Zkoušel jsem už různé věci, ale bez nějakého většího efektu – pořád nestíhá a přitom se klidně fláká. Podle mne by disk měl být schopný data dodávat dost rychle, síťová karta na druhé straně je 100BaseT, tam problém určitě nebude a sběrnice je doufám (?) rychlá dost.
Jakým příkazem bych mohl zjistit jestli procesor čeká / nečeká na data?

[AraxoN]

Ak tie dáta čítaš zo siete, tak tam je nejaké opozdenie. Počas toho opozdenia procesor čaká, ale nezarátava sa to do iowait, ale do idle.

Ak tie dáta po sieti len odosielaš, tak to potom neviem...

[chochi]

Ahoj,

Koukal jsem se do zdrojaku mplayer jak resi paralelni dekodovani u H264, ktera je nejvetsi brzdou.

Nejdrazsi proces pri dekodovani je dekodovani jednoho elementu (kteremu rikaji NAL_SLICE) - toto se snazi paralalelizovat. Bohuzel algoritmus je nasan tak, ze se paralelizace deje jen v ramci jednoho MPEG packetu, ale zatim jsem nenarazil na HD video ktere melo vic NAL_SLICE v jednom packetu (overil jsem si pridani par ladicich informaci pri dekodovani).

Takze nehlede na pocet nastavenych vlaken provadi drahe operace soucasne jen jedno. To ze zadne jadro procesu neni vitizene na 100% neni pravda - akorat jsou k dispozici jen prumerne statistiky (pri zmenseni intervalu mereni zatizeni trebas na milisekundy by to bylo videt).

Predstavit se to da tak, ze pokud ma jadro A 80% a jadro B 20% a meri se po jedne sekunde, tak 0.8s bezelo jadro A na 100% a jadro B na 0% a dalsich 0.2s bezelo jadro A na 0% a jadro B na 100%. Je to dano tim, ze kernel se snazi zatizeni jader vyrovnat.

Samozrejme se pak museji pripocist dalsi hodnoty jako kodovani MPEG2, ktere muze bezet na druhem jadre, takze celkove zatizeni je vic 100%.

[hufhendr]

Příloha:

• performance_x264_2core.png (64503 bytů)

Díky za vysvětlení a díky všem za cenné příspěvky do diskuse. V práci mi už kolegové radili vyměnit procesor a pak i celý počítač, že to nemá smysl.
Díky Vám jsem našel a nainstaloval mplayer-mt a teď už mi to běží pěkně na obou jádrech. Nakonec mi funguje ta ručně kompilovaná verze a mohu potvrdit, že se jeví docela stabilně. Pokud jde o výkon, jsem docela na hraně, pro video 1920x1040 se teploměr bufferu PS3 Media Serveru plní hodně pomalu, přesto stoupá a udrží i krátkodobé klesání v rychlejších scénách. Propady na přiloženém grafu jsou momenty, kdy se buffer spočítaného videa naplnil a procesor si krátce oddech. Teplota procesoru se pohybuje kolem 75°C, větráčky na cca 1200 otáčkách (na začátku filmu až ke 2k) a počítač jde i při tom všem docela v pohodě používat.
Z procesoru se nám povedlo vyždímat maximum a myslím, že tak má před sebou ještě dlouhý křemíkový život.

 

Přidám ještě aktuální statistiky:

# iostat 
Linux 2.6.28-gentoo-r5 (dx2300) 	7.8.2009 	_x86_64_	(2 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          34,07    0,00    2,01    0,94    0,00   62,98

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda               9,50      1009,52       178,77   21844569    3868424

# sar 1 5
Linux 2.6.28-gentoo-r5 (dx2300) 	7.8.2009 	_x86_64_	(2 CPU)

00:51:57        CPU     %user     %nice   %system   %iowait    %steal     %idle
00:51:58        all     72,36      0,00      3,52      0,00      0,00     24,12
00:51:59        all     56,65      0,00      2,46      0,99      0,00     39,90
00:52:00        all     89,60      0,00      3,96      0,00      0,00      6,44
00:52:01        all     84,19      0,00      4,65      1,40      0,00      9,77
00:52:02        all     90,55      0,00      1,99      1,00      0,00      6,47
Average:        all     78,73      0,00      3,33      0,69      0,00     17,25