tar, multithreadová komprese a mt obecně (diskuse)

[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. :)