Quadcore pro gentoo?

5.8.2007 18:00 | Přečteno: 1586× | Linux | poslední úprava: 5.8.2007 18:01

Tento zápis navazuje na Škálování quadcore při kompilaci jádra. Akce prováděne při instalaci software v Gentoo se od překladu jádra značně liší- zdrojáky je třeba stáhnout, rozbalit, opatchovat, nakonfigurovat a po kompilaci ještě nainstalovat a/nebo vytvořit balíček.

Hardware a software

Q6600 @ 3GHz, 4GB DDR2 datarate 830MHz CAS 5

Jádro linux-2.6.22-gentoo-r1, gcc 4.1.2

Metodika měřeni

/var/tmp/portage je umístěn na tmpfs. Měření se provádí pomocí

time emerge nazev > /dev/null

s volbou MAKEOPTS="-j4" resp. MAKEOPTS="-j2". Pozn. Doporučené je nastavit j na hodnotu počet_CPU+1 ale to jsme zde nemohli aplikovat. Pozorováním jak se mění čas při použití -j4 a -j5 jsem zjistil, že výsledek je ovlivněn pouze zanedbatelně. Výběr balíčku: co mi zrovna přišlo pod ruku Všechny potřebné soubory byly předem staženy pomocí emerge -f.

Běžné balíčky

			-j2 [s]	-j4 [s]	j4/j2	
mc 4.6.1-r4		33,17	30,2	91,04 %
gnupg 2.0.5-r1		42,26	38,77	91,75 %
vim-7.1.042 (+vim-core)	73,11	66,45	90,90 %
gtk+ 2.10.14		177,63	145,02	81,64 %
mysql 5.0.4-r1		250,75	202,11	80,60 %
kaffeine 0.8.5		98,77	95,14	96,33 %
krusader 1.80.0		129,42	110,04	85,02 %
qt 3.3.8-r2		284,4	185,34	65,17 %
mplayer 20070622-r3	110,2	75,74	68,73 %
amarok 1.4.6-r4		227,3	191,74	84,35 %
wine 0.9.42		356,92	240	67,24 %
----------------------------------------------
			1783,91	1380,54	77,39 %	

Je vidět, že urychlení ve velké míře záleží na aplikaci, potažmo na poměru neparaelizovatelných činností (rozbalení, patchovani, configure faze...) oproti samotnému překladu a taktéž na tom, jskou míru paraelizace dovoluje Makefile.

Ošklivé balíčky

Bohužel u části balíčků (samozřejmě přesně dl Murphyho zákonů jsou to ve velké míře zrovna ty, které trvají nejdéle) se žádného zrychlení nedočkáme.

			-j2 [s]	j4 [s]	
kdevelop 3.4.1		1158,13	1160,24	100,18 %
kdelibs 3.5.7-r2	988,1	987,12	99,90 %

kdevelop ma vynuceno -j1 už v ebuildu a vytíží proto pouze jedno jádro. kdelibs generuje v průmeru load 1,2.
Co když takové balíčky přeložíme současně a pomůžeme si tak k paraelitě sami? Kdelibs i kdevelop se překladaly v tomto případě o 8 vteřin déle. Důležíte ale je, že jsme celkový čas překladu zkrátili z téměř 37 minut na 19:30.
Je nutno říct, že toto je v podstatě jen teoretická možnost. Předně je třeba dobře vědět co děláme- není např. dobrým nápadem kombinovat komilaci programu a nějaké knihovny na níž program závisí a podobně. Dále pak je možné, že čas strávený přemýšlením nad tím, co mezi sebou zkombinovat bude delší nežli zisk z paraelní kompilace

Quadcore ano či ne?

Pokud uděláme průměr mezi všemi testovanými balíčky (a zamítneme možnost paraelního spouštění emerge) zjistíme, že celkové zrychlení činí pouhých 10 %. Opět si dovolím odvážně zaspekulovat- k dosažení výkonu Q6600@3GHz v této aplikaci by bylo zapotřebí E6600@3,42GHz, což je poměrně běžně dosahovaná hodnota. Na druhou stranu na quadcore si můžete zahrát při kompilaci třeba UT2004 a čas kompilace to zvýší u většiny balíčků pouze zanedbatelně Rozhodnutí nechám na vás.

       

Komentáře

[Heron]

Co na to říct Muže mi někdo vysvětlit proč všichni testují vícecore cpu na JEDNÉ aplikaci? Na živě a světu hardware jsem si už tak nějak zvykl na stupidní testy s ještě horšími závěry, ale od člověka linuxu znalého... Tento test víc než cokoliv jiného ukazuje obtížnost paralelizování kompilace vybraných balíčků ve vybraném kompilátoru, než nevhodnost Quad Core - to srovnání Q a E hovoří za vše. Na E vám 4 nezávislé procesy pojedou v podstatě poloviční rychlostí než na Q.

[miho]

To je test toho, co jak tvrdi zli jazykove, se dela v gentoo nejcasteji tedy instalace pomoci emerge potazmo kompilace. Test quadcore procesrou je nprosto out of the scope tohoto clanku, takze vasi poznamku nechapu.

Kdyz uz tady tak offtopicujeme...

Na E vám 4 nezávislé procesy pojedou v podstatě poloviční rychlostí než na Q.

A co z toho pro uzivatele plyne? Lide nejsou zvykli takhle pracovat. V naproste vetsine chteji, aby byla hotova co nejrychleji jedna konkretni uloha a smitec.

[Heron]

out of the scope tohoto clanku

Tak proč je to v nadpise?

[Michal Vyskočil]

Co to ještě porovnat s překlady v tmpfs?

[miho]

Viz clanek

/var/tmp/portage je umístěn na tmpfs

.

[Ondrej 'SanTiago' Zajicek]

Hmm, jestli je problem s velkum podilem seriove cinnosti pro kompilaci baliku, pak by to chtelo upravit portage, aby bylo schopno kompilovat vic baliku paralelne.

[trekker.dk]

Nechce se mi věřit, že když se při přechodu z -j 1 na -j 2 překlad dvakrát zrychlí, že při -j 2 na -j 4 se nestane skoro nic.

Tipnul bych si, že v procesoru integrovaný řadič by v tomhle případě asi hodně pomohl, ale AMD ještě čtyřjádrové procesory neprodává, takže porovnání nebude. (Ostatně když jsme u toho, ani Intel čtyřjádrové procesory ještě nemá, C2Q jsou dva dvoujádrové procesory propojené přes FSB, což osobně považuju za fintu na diváci.)

[David Jaša]

Tipnul bych si, že v procesoru integrovaný řadič by v tomhle případě asi hodně pomohl, ale AMD ještě čtyřjádrové procesory neprodává, takže porovnání nebude.

Taky bych čul problém tady. FSB je na intelí platformě nejužší místo a s rostoucím počtem procesorů se musí zužovat čím dál tím víc.

[miho]

gcc, linker atd. to jsou vsechno jednovlaknove veci. Nesdileji mezi vlakny a tedy mezi jadry zadna data atd. Takze tady bych v tomto pripade problem opravdu nevidel. Navic vicejadrove procesory- to je novy koncept. Komunikace procesoru skrze externi sbernici tady je uz hoooodne dlouho a nejak se s tm dalo zit i na 64 procesorovych strojich :)

Ja bych tady videl problemy zhruba v tomto poradi:

1) make nema na zaklade Makefile moznost pridelit vsem procesorum praci. Kdyz A zavisi na B a B zavisi na C tak tyto tri cinnosti je proste nutne provest sekvencne. Na 4jadru se projevi samozrejme casteji nez na 2jadru. 2) velky podil neparaelizovanych cinnosti provadenych v emerge (rozbaleni, opatchovani...). Opet na 4 jadru citelnejsi- 75% vykonu behem teto doby lezi ladem

Tyto duvody jsou naprosto dominantni; velka cast vykonu jader je po vetsinu casu nevyuzita.

3) s rostoucim poctem jader roste i zavislost na propustnosti a latencich pameti. 4) s rostoucim poctem jader a j roste pravdepodobnost vzajemneho blokovani se procesu na zamcich v jadru a podobne.

Jak vypada vykon pokud do znacne miry vyloucime 1 a 2 jste si mohli precist v minulem "dilu serialu". Vsimnete si, ze pouze a jen bod 3 je nejak zavisly na hardware...

[xxx]

Neco takoveho jsem chtel presne napsat. V pocitaci je proste spousta komponent sekvencni (pameti, disky, ...). Ceka se take casto na sdilena data.

Dalsi problem bych videl v tom, ze napsat neco pro n vlaken, kde si n dopredu stanovim treba na 2 je jeste pomerne snadne. Ale napsat spolehlive neco pro n, kde se n odvodi az za behu je mnohem slozitejsi. Navic ono pokud si neco vicevlaknoveho zkusite napsat, tak zjistite, ze vas paralelni program zas tak paralelni byt nemusi.

[trekker.dk]

Nesdileji mezi vlakny a tedy mezi jadry zadna data atd. Takze tady bych v tomto pripade problem opravdu nevidel.

Nešlo mi o sdílení dat mezi jádry, ale o paměťovou propustnost. Překlad programu je na práci s pamětí dost náročný...

Kdyz A zavisi na B a B zavisi na C tak tyto tri cinnosti je proste nutne provest sekvencne.

Tady vyloženě záleží na tom, jak je program napsán a rozdělen do souborů. AFAIK překlad většinou probíhá tak, že se nejdřív ze všech *.c zdrojáků přeloží *.o a ty se nakonec slinkují dohromady. Tu první část lze vcelku snadno provést paraleleně. Samozřejmě když je všechno v jednom souboru, tak už to tak jednoduché není.

[jk]

Docela by me zajimalo jak by se 4 jadra projevily na kompilaci programu pouzivajicich cmake. Rekl bych ze cmake umi paralelizovat lepe nez make a navic configure je u cmake daleko rychlejsi.

[genius2000.log]

Stejně si myslím, že nejvíc aktuálně využívají více jádrové procesory nové hry (R6 Vegas, CmR:Dirt, Ghost Recon), ale tam to je většinou dané tak, že jedno jádro (pouze příklad) pracuje s AI, připravuje data pro grafiku a druhé například počítá fyzikální věci. Jenže zde je problém napsat aplikaci univerzálně (1/3/2/4 jádra), tudíž takto to v praxi nefunguje na 100%.