tar, multithreadová komprese a mt obecně

25.7.2010 17:55 | Přečteno: 1589× | Zamyšlení | | poslední úprava: 25.7.2010 17:58

Máme implementovanou spoustu věcí v multithreadu a málokdo toho využívá. To, co mt není, je možné někdy pustit vícekrát vedle sebe a přesto toho málokterý skript využívá... Cílem zápisku je pár lidem maličko rozšířit obzory.

Koupil jsem si notes s procesorem Core i3-350M (2x2.26 GHz + HT), je to můj první Intel a chtěl jsem vyzkoušet jak moc je užitečný HT a jestli se při multithreadingu trvání některých operací zkrátí na míň než poloviční dobu.

Možná znáte lbzip2, multithreadovou implementaci bzip2, která je kompatibilní s původním bzip2. Totéž platí o pigz vs. gzip. Díky tomu lze tyto programy rovnou použít jako "(de)kompresory" pro tar.

Stojí to za to? Posuďte sami. Testy jsou prováděny v ramdisku a RAM jsou dostatečně rychlé (1066 MHz DDR3).

## komprese, 1 vlákno

root@archie /tmp/ram # time tar jcf \
  linux-2.6.35-rc6.tar.bz2 linux-2.6.35-rc6/

real    1m12.235s
user    1m11.982s
sys     0m0.880s

## komprese, 4 vlákna

root@archie /tmp/ram # time tar -I lbzip2 -cf \
  linux-2.6.35-rc6-lbz2.tar.bz2 linux-2.6.35-rc6/

real    0m29.131s
user    1m53.979s
sys     0m1.190s

## dekomprese, 1 vlákno

root@archie /tmp/ram # rm -fr linux-2.6.35-rc6 ; \
  time tar -jxf linux-2.6.35-rc6.tar.bz2 

real    0m23.064s
user    0m22.972s
sys     0m1.450s

## dekomprese, 4 vlákna

root@archie /tmp/ram # rm -fr linux-2.6.35-rc6 ; \
  time tar -I lbzip2 -xf linux-2.6.35-rc6-lbz2.tar.bz2 

real    0m11.928s
user    0m44.347s
sys     0m1.520s

Podobný je to s gzipem a pigz.

## komprese, 1 vlákno

root@archie /tmp/ram # time tar -zcf \
  linux-2.6.35-rc6.tar.gz linux-2.6.35-rc6/

real    0m20.824s
user    0m20.782s
sys     0m0.697s

## komprese, 4 vlákna

root@archie /tmp/ram # time tar -I pigz -cf \
  linux-2.6.35-rc6-pigz.tar.gz linux-2.6.35-rc6/

real    0m7.757s
user    0m29.671s
sys     0m0.793s

## dekomprese, 1 vlákno

root@archie /tmp/ram # rm linux-2.6.35-rc6 -fr; \
  time tar -zxf linux-2.6.35-rc6.tar.gz 

real    0m3.963s
user    0m4.003s
sys     0m0.857s

## dekomprese, 4 vlákna

root@archie /tmp/ram # rm linux-2.6.35-rc6 -fr; \
  time tar -I pigz -xf linux-2.6.35-rc6.tar.gz 

real    0m2.226s
user    0m2.913s
sys     0m0.923s

makepkg v Arch Linuxu vytváří balíčky a může mu to trvat dost dlouho i na nadupaný mašině... je velmi jednoduché si tento shellový skript otevřít v $EDITOR a upravit ho tak, aby používal pigz či lbzip2. lzma/xz bohužel mt implementaci nemá (afaik).

Ještě dodám jeden tip. Nástroj xjobs umožňuje spustit daný příkaz paralelně dle zadání. Nemá cenu abych to nějak detailně popisoval, ukážu vám jak převést všechny wavy na mp3 v aktuálním adresáři a to tak, že ve více vláknech.

for wav in *.[Ww][Aa][Vv]
do
    echo lame -h --preset standard "\"$wav\"" "\"${wav%.*}.mp3\""
done | xjobs -N

Máte-li v názvech souborů mezery či jiné paznaky, xjobs musí dostat uvozovky kolem argumentů tak, jak jsem to předvedl, jinak se to podělá. Výstup potom vypadá takto:

### started job #1, pid 11329: /usr/bin/lame -h --preset standard 101.wav 101.mp3
### started job #2, pid 11330: /usr/bin/lame -h --preset standard 102.wav 102.mp3
### started job #3, pid 11331: /usr/bin/lame -h --preset standard 103.wav 103.mp3
### started job #4, pid 11332: /usr/bin/lame -h --preset standard 104.wav 104.mp3
### job #1 (/usr/bin/lame -h --preset standard 101.wav 101.mp3), pid  11329, exitcode 0, real: 27.3 secs.
### started job #5, pid 11348: /usr/bin/lame -h --preset standard 105.wav 105.mp3
### job #3 (/usr/bin/lame -h --preset standard 103.wav 103.mp3), pid  11331, exitcode 0, real: 31.47 secs.
### started job #6, pid 11352: /usr/bin/lame -h --preset standard 106.wav 106.mp3
### job #2 (/usr/bin/lame -h --preset standard 102.wav 102.mp3), pid  11330, exitcode 0, real: 31.7 secs.
### started job #7, pid 11353: /usr/bin/lame -h --preset standard 107.wav 107.mp3
### job #4 (/usr/bin/lame -h --preset standard 104.wav 104.mp3), pid  11332, exitcode 0, real: 32.01 secs.
### started job #8, pid 11354: /usr/bin/lame -h --preset standard 108.wav 108.mp3
### job #5 (/usr/bin/lame -h --preset standard 105.wav 105.mp3), pid  11348, exitcode 0, real: 29.73 secs.
### started job #9, pid 11370: /usr/bin/lame -h --preset standard 109.wav 109.mp3
### job #8 (/usr/bin/lame -h --preset standard 108.wav 108.mp3), pid  11354, exitcode 0, real: 27 secs.
### started job #10, pid 11374: /usr/bin/lame -h --preset standard 110.wav 110.mp3
### job #7 (/usr/bin/lame -h --preset standard 107.wav 107.mp3), pid  11353, exitcode 0, real: 29.69 secs.
### started job #11, pid 11375: /usr/bin/lame -h --preset standard 111.wav 111.mp3
### job #10 (/usr/bin/lame -h --preset standard 110.wav 110.mp3), pid  11374, exitcode 0, real: 30.92 secs.
### job #6 (/usr/bin/lame -h --preset standard 106.wav 106.mp3), pid  11352, exitcode 0, real: 59.85 secs.
### job #11 (/usr/bin/lame -h --preset standard 111.wav 111.mp3), pid  11375, exitcode 0, real: 32.18 secs.
### job #9 (/usr/bin/lame -h --preset standard 109.wav 109.mp3), pid  11370, exitcode 0, real: 41.95 secs.

Něco podobného jako xjobs umí i standardní nástroj xargs, ale má jistá omezení, která nelze obejít, proto tam kde to lze je lepší použít xjobs.

       

Komentáře

[disorder]

Stojí to za to? Posuďte sami.

cele zle

[Damian]

Ty si komplet cely zly aj s tvojim fotrom...

[David Watzke]

Můžeš se trochu rozpovídat? Takhle je tvůj komentář je užitečný, jako automat na kondomy ve Vatikánu.

[brk]

To možná nebylo nejlepší přirovnání. Ve Vatikánu je třeba legální sex od 12 let a čert ví, co se tam ještě děje.

[David Watzke]

No jo, ale nechtěl jsem na něj hned vytahovat mytické lízátko s příchutí hoven.

[disorder]

cas kompresie si moze odstopovat kazdy aj sam a navyse to aj bude na relevantnom hardveri

posudil som teda sam, ze tento blog je uplne na nic

[Michal Fecko]

Posudzuj vtedy ked nieco zmysluplne stvoris sam...

[disorder]

osviet ma, coze tu bolo storene? par pastnutych vypisov z time? bez akychkolvek zaverov? strata casu pisat aj citat to

[Michal Fecko]

Rovnako ako to tu nemusis čítať, nemusíš to tu ani komentovať... A ušetrený čas využi na niečo čo keď spravíš tak nám všetkým spadne sánka...

[disorder]

ty si nejaka mudra hlava, vraj pokusat sa ohurit ludi na internete :D

[Michal Fecko]

Zalez troll...

[Grunt]

par pastnutych vypisov z time

Co to zas meleš?

[Jendа]

Mně se to líbilo, samotnému by se mi to dělat nechtělo, takhle jsem se rovnou podíval na výsledky.

[Jendа]

Ou. Sice jsem myslel, že komentuji reakci na Gruntův zápisek, ale tady to platí taky.

[Grunt]

No já hlavně nepochopil to:

par pastnutych vypisov z time? bez akychkolvek zaverov?

To jako že výpis z programu time není závěr a ještě ho potřebuje v písemné formě nebo jak? A netrpí ten člověk náhodou nějakou mentální poruchou?

[zulu]

Jo, bez vemena nemas pravo rict, jak ti mleko chutna.

[David Watzke]

Aha, takže nepochopil. Nejde tu o žádný hloupý časy na mym zaprděným hardwaru, copak to není jasný? Jde mi o to ukázat lidem, co to ještě nevědí, že můžou při kompresi naplno využívat svoje nařachaný procesory!

[Heron]

Dobré. +1

Dlužno dodat, že s multithreadingem je podobné jako s 64b. Postupuje to hrozně pomalu. Přitom víceprocesorové systémy tu jsou de facto od vzniku počítače samotného. PC se to, pravda, hodně dlouho vyhýbalo (s prvním domácím multiCPU PC jsem se potkal až v 1997).

Já vidím jednoznačně chybu na straně programátorů. To, že se jim nechce přepisovat algoritmy (ne vždy to jde) do vláken, to se dá pochopit. Ale to, že úlohy zpracování mnoha paralelních dat (např. uvedené konverze mediálních souborů) nejsou v roce 2010 schopni paralelizovat, to je neomluvitelné. Druhý nejpoužívanější prohlížeč (FF) až teď (jak dlouho se prodávají multijádra?) nesměle a částečně něco přepisuje. O jeho podpoře 64b (pokud by někdo chtěl žvatlat něco o tom, na co browser potřebuje "tolik" paměti, tak za poslední měsíc jsem těch 2GB u FF několikrát vyčerpal a nebyl to memory leak), ani nemluvím.

[xHire]

Jak jsi přišel na to, že tar s lbzip2/pigz vytvoří vždy přesně 4 vlákna? Spíš bych předpokládal, že když už se to přesně nespecifikuje v argumentu, tak to bude vytvářet efektivní počet vláken a nebude se to odvíjet jenom od toho, kolik výpočetních jednotek má systém k dispozici. Ale pro jistotu se ptám, protože jsem se dovnitř nekoukal a nevím to. Jen mi přišlo divné, jak to tam máš s naprostou samozřejmostí napsané.

[David Watzke]

U mě to běží ve 4 vláknech (to je relevantní pro to měření), jinak je doufám pochopitelný, že to spočítá logický procesory (atp., záleží o jakej program jde) a pustí to patřičnej počet procesů.

[Grunt]

Ty jo, tak za xjobs díky. O tom jsem nevěděl. Škoda jen, že nemám víc jader nebo procesorů.

[pht]

Nástroj xjobs umožňuje spustit daný příkaz paralelně dle zadání.

xargs taky. a samozřejmě make.

[David Watzke]

O xargs jsem psal přece make je jasnej, ten nebýt paralelní, tak jsem asi fakt v dobách Gentoo kompiloval 100 % času

[brk]

... v dobách Gentoo ...

A teď je co za doba? :o)

[David Watzke]

Pro mě je doba Archu

[iki]

Imho je post-gentoo doba casto dobou Archu, ale i dobou Sabayonu. Nejspis je tedy sama paralelni :)

[iki]

Krome toho, ze gentoo doba samozrejme trva dal :)

[Luboš Doležel (Doli)]

Zajímalo by mě, jak rychle ti to dá ve dvou vláknech - tedy jestli je to s HT opravdu rychlejší.

[Semo]

Pred cca 5 rokmi, na Pentiu 4 D = 1 jadro, s HT sa tvari ako 2 jadra trvala realna kompilacia jadra 7m:30s, so zapnutym HT trvala 6m:30s. Pri kompilovani v ramdisku by asi vysli vyraznejsie rozdiely.

[Heron]

To by byl zajímavý test ale musel by se udělat jinak:

Otestovat danou úlohu pro 1-10 vláken při zapnuté podpoře HT a pak totéž při vypnuté podpoře HT. Aby to mělo alespoň nějakou váhu, tak ještě každý test zopakovat, takže dohromady nějakých 120 testů (ale je to automatická činnost).

Ono totiž optimální počet běžících procesů je obvykle počet cpu+1 (konkrétně je to třeba zjistit testy pro danou úlohu a HW). Tedy pro 3 vlákna i na dvoujádru bez HT dostaneš lepší výsledek než pro dvě. Jo, takže bez vypnutí HT vlastně nezjistíš, zda je ten výkon navíc přínos HT a nebo lepšího využití procesorového času.

[David Watzke]

root@archie /tmp/ram # time tar cf - linux-2.6.35-rc6/ | \
  lbzip2 -n 2 > linux-2.6.35-rc6.tar.bz2.2

real    1m15.019s
user    1m14.455s
sys     0m1.363s

root@archie /tmp/ram # time tar cf - linux-2.6.35-rc6/ | \
  lbzip2 -n 4 > linux-2.6.35-rc6.tar.bz2.4

real    0m53.931s
user    1m47.243s
sys     0m1.093s

[Jendа]

A teď ještě vypni HT a spusť čtyři vlákna…

[David Watzke]

Hmm, vypnul jsem procesor id 1 a 3

real    0m55.491s
user    1m47.746s
sys     0m1.577s

že by zde HT bylo na prd?

[Michal Kubeček]

Úplně na prd není, ale rozhodně si člověk nesmí představovat, že si za stejné peníze koupil dvakrát tolik procesorů. Navíc za určitých okolností může hyperthreading dokonce i škodit (modelový příklad: jednojádro s hyperthreadingem a dva procesory s výrazně odlišnými prioritami).

[David Watzke]

Já vím, četl jsem si o tom pár věcí. Viděl jsem nějaký benchmarky na tomshardware, kde testovali Core i7 a zjistili, že HT výkon ovlivňuje -2 % až +30 % (jak při čem), takže to je docela dobrý.

[optim]

V hodnoceni HT bych byl opatrnejsi, na onom jak pri cem zalezi opravdu hodne.

Jinak tihle rusaci casto testovali podobne veci, jako HT on/off, TB on/off, single/dual/.. channel, ganged/unganged, apod., na ktere ostatni hazeli bobek nebo udelali 3 testy a delali chytry.

[Michal Kubeček]

Nechcete-li být jednoho dne nepříjemně překvapen, zvykněte si dávat přepínač určující režim práce (-c, -x apod.) jako první. Některé verze taru to vyžadují.

[David Watzke]

Dík za info, já ty přepínače vždycky tak nějak poskládám, aby mi to fungovalo... u taru mi to jejich zpracování přijde nějaký divný.

[Neneko]

Příloha:

• pigz_1_20.png (4874 bytů)

Diky.

Jen vic takovych zapisku, at si lidi uvedomi, ze ma smysl se dozadovat podpory mt kde to jen jde ;)

Zkusil jsem to pro pigz na stroji s 16 logickymi jadry (2x Xeon 5520 - 8x 2.27GHz + HT).

Pro kazdy pocet cpu se test opakoval 10x a vysledek je prumer danych hodnot. Testovano pro 1 - 20 vlaken. Cteni i zapis na ramdisk (tmpfs). Jako data pouzit vanilla kernel 2.6.33 ;)

Spousteno z pythonu jako: subprocess.call('tar cpf - linux-2.6.33 | pigz -p ' + str(cpus) + ' >linux.2.6.33.' + str(cpus) + '.tar.gz',shell=True)

Prinos MT je tam videt (27s jedno jadro, 2.7s 15 jader). Cas klesal do 8 pouzitych jader docela rychle, pak to zacalo hodne zpomalovat, tak na prvni pohled HT asi tak moc nepomohlo. Treba to ale zpomaluje neco jineho (tar to nebrzdi, ten zvladne udelat cely archiv behem 0.75s)

1: 26.948592
2: 12.978853
3: 8.386309
4: 6.496362
5: 5.147390
6: 4.600060
7: 3.709489
8: 3.520402
9: 3.389651
10: 3.212332
11: 3.044059
12: 2.927873
13: 2.852460
14: 2.741924
15: 2.676069
16: 2.721835
17: 2.764356
18: 2.782042
19: 2.759746
20: 2.776046

[lok]

Pekny zapisek, diky. :)