Dvě jádra na dvě věci

1.11.2006 13:27 | Přečteno: 2471× | Ani zbla

Tuhle jsem vyráběl nějaký .tar.bz2 souborek a docela jsem se u toho nudil. Tak z té nudy koukám na vytížení procesoru a svítí tam 50%. To proto, že na svém noťasu mám Core Duo a bzip2 je samozřejmě schopen využít jen jedno jádro. Jo, asi jsem si k tomu měl pustit ještě Kvejka, ale hry nehraju

Už se těším, až budu mít za pár let osmijádrový procesor a budu se nudit u využití 12.5%.

Ten notebook jsem si pořídil, aby se mi dobře programovalo v Javě. Speciálně pro náš informační systém (hromada javy a hromada dat v databázi) jsou 2 jádra super. Ale více jader taky znamená, že většina softu, co používám je, vlastně dost zastaralá. Kdo nahackuje vícevláknový bzip2? (Tuším, že bz2 pracuje po nezávislých blocích, tak by to nemusel být velký problém?) Nebo jak se bude muset změnit přístup k programování, aby programy hezky běžely na dnešním a zítřejším železe?

       

Komentáře

[zabza]

To není tak docela pravda, že jsou ty dvě jádra na ... to .. nic. Náhodou si můžete ten bzip2 pustit dvakrát!

[alblaho]

Jo. A v budoucnu třeba osmkrát.

[J.]

U vicejader taky doporucuju poradne vyuzivat roury, tam se projevi (treba spojeni tar a bzip2).

[alblaho]

V tomhle konkétním případě právě ne. Tar procesor (skoro) vůbec nepotřebuje.

[fakenickname]

myslim ze u takoveho 80GB archivu co sem posledne rozbaloval by jste se docela divil.. ;)

[Quactuda]

A co parallel bzip2 implementation??

http://compression.ca/pbzip2/

[alblaho]

Výborně, bz2 máme vyřešeno!

alblaho@alblahowrk:~$ pbzip2
bash: pbzip2: command not found
alblaho@alblahowrk:~$ su
Password:
root@alblahowrk:/home/alblaho# apt-cache search pbzip2
pbzip2 - parallel bzip2 implementation
root@alblahowrk:/home/alblaho# apt-get install pbzip2
Reading package lists... Done
Building dependency tree... Done
The following NEW packages will be installed:
  pbzip2
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 21.3kB of archives.
After unpacking 81.9kB of additional disk space will be used.
Get:1 http://cz.archive.ubuntu.com dapper/universe pbzip2 0.9.5-1 [21.3kB]
Fetched 21.3kB in 0s (128kB/s)
Selecting previously deselected package pbzip2.
(Reading database ... 130636 files and directories currently installed.)
Unpacking pbzip2 (from .../pbzip2_0.9.5-1_i386.deb) ...
Setting up pbzip2 (0.9.5-1) ...
root@alblahowrk:/home/alblaho# exit
exit
alblaho@alblahowrk:~$ pbzip2
Parallel BZIP2 v0.9.5 - by: Jeff Gilchrist [http://compression.ca]
[Dec. 31, 2005]             (uses libbzip2 by Julian Seward)

** This is a BETA version - Use at your own risk! **

[Quactuda]

Vic procesoru(jader) nemam a celkem by zajimalo, jak rychle to umi rozbalit(zabalit) archiv oproti klasickemu bzipu.

[trekker.dk]

Tipnul bych, že přibližně dvakrát rychleji

[Quactuda]

To zni skoro tak prilis optimisticky, az skoro nerealne(==2x zrychleni) Ne, zajimalo by me, zda to vubec prakticky pouzitelne pro beznou praci, kdyz tam pisou, ze je to beta.

[alblaho]

Tak, na mem dvoujadrovem ntb to stejne nejede.

alblaho@alblaho:~/links/src$ time cat linux-2.6.18.tar.bz2 > /dev/null

real    0m0.037s
user    0m0.004s
sys     0m0.032s
alblaho@alblaho:~/links/src$ time bzip2 -k -d -c linux-2.6.18.tar.bz2 > /dev/null

real    0m20.708s
user    0m20.649s
sys     0m0.048s
alblaho@alblaho:~/links/src$ time pbzip2 -k -d -c linux-2.6.18.tar.bz2 > /dev/null
terminate called after throwing an instance of 'std::bad_alloc'
  what():  St9bad_alloc
Aborted

real    0m27.754s
user    0m27.386s
sys     0m0.364s
alblaho@alblaho:~/links/src$ time pbzip2 -p2 -k -d -c linux-2.6.18.tar.bz2 > /dev/null
terminate called after throwing an instance of 'std::bad_alloc'
  what():  St9bad_alloc
Aborted

real    0m27.898s
user    0m27.506s
sys     0m0.328s

[Martin Beránek]

mě jo

$ time cat test.tar > /dev/null
real    0m0.059s
user    0m0.003s
sys     0m0.055s

$ time bzip2 test.tar
real    0m31.991s
user    0m31.647s
sys     0m0.237s

$ time pbzip2 test.tar
real    0m17.461s
user    0m33.662s
sys     0m0.813s

[Zdeněk Štěpánek]

Myslim si ze pri soucasnych programech se dvoujadro na beznem desktopu az tak uplne nevyuzije. Samozrejme to znat bude, ale ne jako dvojnasobny narust frekvence CPU (respektive suroveho vykonu, cache atd).

Kde ma dvoujadri mimo jine vyuziti je napriklad aplikacni server pro tenke klienty. Uz mi to ve skole uspesne bezi a chudak celeron 2.66Ghz se pekne zapoti, az tam bude core duo nebo neco takoveho (prosim prosim aspon procak kdyz uz ne celej server samozrejme s opteronem) tak to si pak poprede jak spokojena kocka.

Zdenek

[zabza]

Já teda nevim, ale v normálním systému přece není potřeba, aby jedna úloha běžela na dvou procesorech. Stačí že můžou běžet dvě úlohy zárověň. Jo, vím, není to tak jednoduchý jak píšu, ale rozhodně není žádná katastrofa, že programy nepoužívají paralelní zpracování, jak se snaží naznačit blogpost...

[Luk]

Problém je v tom, že když se procesor změní tak, že se sice zvedne celkoový výkon o 20 %, ale ve skutečnosti se z jednoho jádra stanou jádra dvě, každé o výkonu 60 % toho původního, jednovláknový program na tom poběží pomaleji. Proto je k plnému využití vícejádrových procesorů paralelizace nutná.

Tím neříkám, že jsou vícejádrové procesory dobrou cestou. Paralelizace za každou cenu je cesta do pekel, přinese zvýšenou režii na dělení práce a synchronizaci přístupu, a samozřejmě vygeneruje spoustu zbytečných bugů, které se budou špatně hledat.

[Quactuda]

Tím neříkám, že jsou vícejádrové procesory dobrou cestou. Paralelizace za každou cenu je cesta do pekel, přinese zvýšenou režii na dělení práce a synchronizaci přístupu, a samozřejmě vygeneruje spoustu zbytečných bugů, které se budou špatně hledat.

Paralelni programy jsou rozhodne narocnejsi k naprogramovani a debugovani, ale ta zvysena rezie bude uzivatele spise bolet prave u procesoru s jedinym jadrem nez u vicejadrovym procesoru, tam naopak pomuze vyuzit lepe potencial procesoru. Na druhou stranu, ono neexistuje do budoucna zas tolik moznosti, jak zvysovat vykon procesoru, obzvlast pokud uz dneska se zacinaji blizit svym technologickym moznostem a fyzikalnim omezenim.

[Luk]

Na druhou stranu, ono neexistuje do budoucna zas tolik moznosti, jak zvysovat vykon procesoru, obzvlast pokud uz dneska se zacinaji blizit svym technologickym moznostem a fyzikalnim omezenim.

Určité možnosti jsou. Například:

1. Větší aktivita v oblasti RISC procesorů. RISC má - vzhledem ke konstrukci - fyzikální limity relativně dále než CISC. Tím spíš, že zrovna třeba u procesorů x86 instrukční sada přímo bují a počet potřebných tranzistorů rychle narůstá.
2. Specializované procesory. Mnoho věcí může dělat např. GPU. Hlavní procesor by pak ani nemusel obsahovat instrukce typu MMX nebo SSE.
3. Výzkum v oblasti kvantových technologií a konstrukce procesorů založených na kvantových jevech (já vím, to je běh na dlouhou trať).

A když už používat vícejádrové procesory, tak by neškodilo se trochu zaměřit na překladače (kompilátory, interprety), aby byly schopny paralelizovat samy od sebe. Pochopitelně bych to nepožadoval u C, ale třeba Java nebo Python by se mohly vydat tímto směrem. Umožňovalo by to efektivnější a kvalitnější vývoj.

[petr_p]

Výzkum v oblasti kvantových technologií a konstrukce procesorů založených na kvantových jevech (já vím, to je běh na dlouhou trať).

Nedavno jsem shledl uvod do kvantove kryptografie (zaznam z roku 2003), kde prednasejici zminuje, ze cesta ke kvantovemu pocitaci se zatim odhaduje na stovky let. Zatim jsme pry schopni uchovat nejvysse 10 b informace.

[Luk]

Až přijde nějaká pořádná válka, ono se to pohne. Tedy ne že bych ji přivolával

[kaaja]

Kdysi jsem byl v ramci svych studii na jednom seminari od Sunu o paralelizaci a optimalizaci. Bylo to dvoudenni (zadarmo) zamerene na vypocetni ulohy - hlavne jak parelelizovat cykly. A ten Suni compilator C umel paralelizovat sam. Stacilo dat jenom spravny parametr pri prekladu a pak pre behem nastavit jednu promennou prostredi.

Take jsem videl kompilator Fortranu na nejake masine od SGI, ktery umel paraelizovat take sam.

[kaaja]

No chce to presvědčit programátory, aby do svých programů přidávali OpenMP a pak bude stačit, aby se program skompiloval s openMP (gcc 4.2 to umi) a pak to samo poběží na více procesorech.

[Quactuda]

Jenze ono zalezi, jestli lze skutecne ten program paralelizaci zrychlit, ci ne. Souhlasim s LUkem v tom, ze za kazdou cenu to nema smysl.

[kaaja]

Ano to je pravda, Pokud se navic to udela blbe, tak program muze bezet i pomaleji. Videl jsem ukazkovy program, ktery na vice procesorech bezel pomaleji - furt se musela synchronizovat cache a bylo to na houby.

[Heron]

Tak nevím. Při jakémkoliv srovnání, nebo povídání o vícejádrových procesorech je uvedeno, že jeden program využije jen jedno jádro a to druhé je jakoby k ničemu. To je sice pravda, ale na PC neběží je jeden program (pokud u vás ano, tak se omlouvám ), takže i kdyby existovaly výhradě single-threading programy, tak se vícejádro vyplatí. Nevím jak jinde, ale u mě na single core mám load > 2 (a to téměř na všech strojích, které používám).

[Luk]

Hmmm... Pokud někdo na svém desktopu pátrá po mimozemšťanech nebo hledá lék proti rakovině, tak se druhé jádro hodí. Ale když to tak vezmu, tak při běžné práci na desktopu (pokud mi současně neběží na pozadí třeba zpracování videa) požírá čas procesoru skoro vždycky především hlavní vlákno toho programu, se kterým zrovna pracuji. Ať už je to vývojové prostředí, editor, grafický program nebo webový browser.

[thingie]

Když někdo pustí pažravou úlohu, tak ta může zapráskat jenom jeden procesor a když jich máte víc, ani to nepoznáte, jenom ji v klidu odstřelíte

[Luk]

Pažravou úlohu lze v klidu odstřelit i na jednom procesoru. Tedy aspoň pokud nemá nice -20 (případně realtime prioritu)

[AloneInTheDark]

Ahoj, tady je docela pekny clanek o porovnani vykonu intel dual core cpu a amd. Je to uz trochu starsi, ale za precteni to stoji. Porovna va se dvd rip a encoding, komprese souboru, kompilovani kernelu a nejaka hra. http://www.anandtech.com/linux/showdoc.aspx?i=2463

[Ondrej Sykora]

Hm, ten test ale srovnava vykon AMD X2 se "starymi" dual core pentii, coz jsou uplne jine procesory nez Core2. Doporucuju hledat nejaky test zabyvajici se aktualnimi procesory ;)
Nejaky (prvni, co jsem nasel) je treba tady http://www.linuxhardware.org/article.pl?sid=06/08/22/0415251 Jeste k puvodnimu postu:
1) a jak moc tu dekompresi brzdi procesor a jak moc ji brzdi disk? Nestala by za zamysleni i takovahle otazka?
2) treba takovy make umi spoustet vic uloh najednou, takze pri vyvoji se vic procesoru urcite vyuzije, to same pri soucasnem behu vic aplikaci (typicky pripad pracovni stanice s X).

[kutom]

Jenze amd x2 a pentia jsou konkurenti. Amd proti core2 zadnou alternativu zatim nema.

[blogsm]

Mám taky dvoujádro na notesu, a přínos je pouze, pokud to nebrzdí něco jiného. To může být buď disk (často. Třeba nemůže běžet současně test na viry společně s testem na spyware. Obojí je náročné na hdd.), paměť (v notesu mám "pouze" 512, takže by mi to mohlo pomoct při více programech spuštěných najednou. Problém je, že více programů zabírá více ram.) nebo uživatel (to u mně opravdu nechrozí 8-))

[David Watzke]

Třeba nemůže běžet současně test na viry společně s testem na spyware.

Správně. Proto nikdo nepoužívá Windows.

[blogsm]

To byl příklad. Nenapadla mě rychle jiná činnost, při které se využije HDD i CPU.

Správně. Proto nikdo nepoužívá Windows.

Opravdu nikdo?

[David Watzke]

Jen nejapný žert...

[Heron]

Přesně tak. V linuxu dva programy přistupující k jednomu disku, běží stejně dobře, jako jeden program samostatně. Opravdu demagogie...

[David Watzke]

Zrovna od tebe byl čekal, že to pochopíš

[b*d]

Ano běží. Narozdíl od Windows XP prof SP2 linux umí obsloužil můj disk s native queries, takže je to samozřejmé a nechápu čemu se divíte.