Škálování procesorů při kompilaci jádra (diskuse)

[vlastikroot]

Lidi tady zkoušejí 8mi jádrové procesory a já nikdy neměl ani dvoujádro Ale pěkné, je vidět, že pres make se dají věci pěkně paralelizovat.

[Nicky726]

Nejsi sám.

[Grunt]

No nádherně. Fakt. Člověk by přitom řekl, 8x 2Ghz = 8x 2Ghz a přitom může být rád aspoň za něco.

[miho]

Ve skutečnosti je šestinásobné zrychlení na osmi jádrech velice hezkým výsledkem... Proč tomu tak je viz jeden můj starší článek.

Komu se nechce nic číst, si může raději spočítat, jaká část výpočtu musí být paralelizovatelná aby došlo k takovému zrychlení. Nápověda1: Amdahlův zákon, Nápověda2: výsledek je 95 %

[Grunt]

No tak to je ještě lepší. Takže vlastně narážíme na další limit. Zato čím víc jader o to dražší procesor, ale o to menší reálná rychlost zpracovávání a o tom větší marži necháváme obchodníkům. Doufám, že se honem něco vymyslí, protože vypadá to, že s frekvencí už se nikomu hýbat nechce, ten počet jader je takový…no. Zbyde už max. tak jenom optimalizace což je bohužel horší než s tou frekvencí a počtem jader.

[CET]

A nebo si koupit vic masin, jednu normalni s diskama, dalsi jenom nejaky minicase se sitovkou bez disku. Hlavne vsechny s levnyma CPU. Pak pres NFS udelat disky pro ty malinky bezdiskovy, nahodit distcc a jede se jako na SMP. Je to srovnatelny? Pripadne, aby to nebrzdil soucasny pristup na disk pres NFS z tech malych stanic, tak lokalne pouzivat ramdisk.

[Grunt]

Já bych řekl, že u jednoho úkolu je vcelku jedno jestli na tom pracuje jedno jádro, jeden procesor nebo jeden počítač. Ten problém s paralelismem trvá furt dál.

[deda.jabko]

amdahluv ,,zakon'' je sice priserna bestie... ale dikybohu neplati obecne. problem je nasledujici. amdahluv zakon se uvazuje ve forme, ze maximalni zrychleni v zavislosti na poctu procesoru je S(N) = 1/((1 - P) + (P / N)), kde P je cast algoritmu, ktera musi bezet sekvencne a N je pocet procesoru.

problem je, ze P nemusi byt konstanta. hodnota P je dana vstupnimi daty. coz je vicemene intuitivni, ma cenu paralelizovat velke ukoly nez male. a taky a to je hlavni, jsou pripady kdy P je funkci N... coz meni vyzneni celeho ,,zakona'', i.e., jde dosahnout linearniho i super-linearniho zrychleni! to znamena, ze v nekterych pripadech jde treba na dvoujadrovem procesoru dosahnou 10x zrychleni.

na druhou stranu, v pripade parallelniho programovani je potreba prehodnotit cely pristup k navrhu algoritmu a programu... protoze zkusenosti ze sekvencnich algoritmu jsou v pripade parallelnich algoritmu vicemene k nicemu.

[miho]

Proč ach proč se mi pokaždé, když píšu o škálování takové věci jako třeba kompilace, stává, že se někdo vytasí se superlineárními algoritmy? Je to tím, že naše vysoké školství produkuje praxií nepolíbené teoretiky-idealisty? Jinak si to neokážu vysvětlit Ale tady asi ani to ne páč 10x zrychlení na dvoujádru to ned8 ani backpruning, to je něco naprosto z jine galaxie řekl bych

[deda.jabko]

a proc kazdy, kdo si parallelne skompiluje kernel a precte par veci na wikipedii, si mysli, ze rozumi parallelnimu programovani?

vysoké školství produkuje praxií nepolíbené teoretiky-idealisty

:-]]

to je něco naprosto z jine galaxie řekl bych

to je jasne... svuj notas jsem koupil od dvou ferengu pri ceste po gama-kvadrantu! puvodne jsem ho ani nechtel, ale nakonec jsem se nechal ukacat. :-]

Ale tady asi ani to ne páč 10x zrychlení na dvoujádru to ned8 ani backpruning,

takze taky teoretik? v praxi lze dosahnout superlinearniho zrychleni i s ,,beznyma parallelnima'' programama. staci si uvedomit, ze realny program nepouziva jenom CPU... a nadesignovat pak experiment, kde vyjde desetinasobne zrychleni na dvoujadru je uz jenom otazka cviku a trochy praxe. ;-]

[miho]

Netvrdím nikde, že jsem odborník na paralelní programování, ale alespoň to nepíšu se dvěmi l To není k smíchu s tím školstvím, já jsem také jeho produktem, vím o čem mluvím

Tak mi nějaký takový experiment vycházejiící z praxe na reálném hardware a ne z akademického myšlenkového pokusu ukaž. Už jsem viděl i pokus o naprosto vyumělkované vytvoření algoritmu, který sázel na to, že se jeho working set vejde do L2 procesorů při rozdělení na víc části ale jako celek ne. Teoreticky vysněný případ. V praxi byl zisk jen nějakých 60 % páč se nepočítalo s n-asociativitou cache v reálných procesorech takže docházelo k přecpání některých řádků a na tom to celé zvadlo.

[deda.jabko]

To není k smíchu s tím školstvím, já jsem také jeho produktem, vím o čem mluvím

ja jsem se smal necemu uplne jinemu... :-]]

Tak mi nějaký takový experiment vycházejiící z praxe na reálném hardware

vezmi si nejaky program a do jeho vlaken si pridej parkrat volani sleep(). uvidis, jaky to bude mit vliv na skalovani. ted si vem ten program a misto volani sleep si tam domysli, cekani na diskove I/O, cekani na sit, atd. bohuzel, z jistych duvodu nemuzu byt konkretnejsi...

[miho]

Tak tim jsi to zabil naprosto. Čím víc bude aplikace čekat na I/O a méně počítat tím bude škálovat hůře protože bude stale více a více bržděná úzkým hrdlem I/O. Ale i kdybys magiky přidáním threadu namnožil i celý diskový subsystém tak stále víc jak dvojnásobek výkonu ze dvou threadů nevymáčkneš.

[deda.jabko]

Tak tim jsi to zabil naprosto.

to si jen myslis, nebo jsi to i zkousel? na I/O se musi cekat za vsech okolnosti v sekvencni i nesekvencni variante. jenomze v pripade nesekvencni varianty, zatimco jeden proces ceka na vyrizeni I/O, dalsi muze vyuzivat procesor. jeste bych mel dodat, ze aby to fungovalo (mimo amdahluv zakon) je potreba, aby pocet procesu byl vetsi nez procesoru.

[miho]

Pořád to v tom nevidím. Pokud je celek omezen I/O (většina procesů čeká na I/O a stává se často, že je procesor nevyužitý) tak přidání dalších procesorů a procesů nepřinese prakticjky žádný zisk protože úzké hrdlo zůstane stejné. Pokud naopak většina procesů čeká na procesor tak se logicky (téměř) nikdy nefláká a přidání procesoru a procesů sice pomůže výkonu ale zase maximálně na dvojnásobek protože zvětěíme úzké hrdlo na dvojnásobek.

Což takhle ukázka, do kostry pthreads aplikace napasovat nejskou simulaci výpočtu a IO a počítadlo iterací... půl hodinky. Nebo alespoň odkaz na něco, co takhle krásně škáluje.

[deda.jabko]

Pořád to v tom nevidím.

pointa je v tom, ze I/O se zacne chovat jako dalsi procesor. vezmi si jako trivialni pripad treba jednoprocesorovy stroj s dvema vlaknama, kdy se musi stridave cist a zpracovavat data... zatimco jedno vlakno cte data (nepotrebuje procesor), druhe pracuje... takze uloha skaluje i kdyz by vlastne nemela.

Což takhle ukázka, do kostry pthreads aplikace napasovat nejskou simulaci výpočtu a IO a počítadlo iterací... půl hodinky. Nebo alespoň odkaz na něco, co takhle krásně škáluje.

zkus si to naprogramovat sam, hint jsem dal vys. ja uz jsem touto diskuzi zabil vic casu nez je zdravo. a taky diskuzi o tom, ze ten a ten priklad neni optimalni nebo ze neodpovida realite jsem si uzil uz vic nez dost.

[default]

A mně celej den vyměňovali stoupačky. Voda teče z prdele, ale kafe si uvařim a umejt se umeju.

[Grunt]

Přesné hodnoty někde dostupné jsou?

[miho]

Tady.

[Grunt]

Děkuji.

[petr_p]

Čím si vysvětlujete, že při -j2 se dvoujádro propadlo? Je to tím, že I/O dělají jiná jádra, než na kterých jede výpočetní proces? Nebo to je tím, že dva procesy rotují přes více procesorů? (U čehož bych pochyboval o kladném vlivu na cache, nebyla to NUMA, že?)

[miho]

Stejně tak došlo k poklesu čtyřjádra při -j4 oproti osmijádru. Měřeno bez grafického prostředí, všechno jsem povypinal včetně věcí jako syslog-ng aby byl výsledek co nejméně ovlivněn, takže v tom problém není. Jediné vysvětlení, ktré mě napadá je, že dvoujádro má 6 MiB L2, čtyřkádro 12 MiB a "osmijádro" 24 MiB. Když se 4 procesy rozdělí rovnoměrne mezi procesory tak maji efektivně dvojnásobek L2 k dispozici. Ale jen hádám.

[cthulhu]

rychlosti RAM / disku behem poslednich let stagnovaly a CPU tak permanentne ceka na data. Proto se par chytrych hlav v Sunu dalo dohromady a vyvinuli pred peti lety CPU pod kodovym oznacenim Niagara (v soucasnosti 64 threadu per CPU tj. az 128 hw vlaken v 1U serveru). idealni na masivni multithreading (web servery, OLTP, LDAP, mail..) v kombinaci se Solarisem, ktery je s featurami a supportem stale pred jakymkoliv linuxem - bohuzel i cenou..No jeste maj x86 co dohanet.

[deda.jabko]

niagara jsou, co se tyce skalovani, hodne dobre procesory. mam k dispozici jednu niagaru T1 a skaluje fakt pekne, ale vykon jednotlivych ,,procesoru'' za x86 hodne kulha.

[cthulhu]

tento nedostatek castecne dohani inovovana T2ka, ktera ma 1 FPU per core (T1 mela 1 FPU na cely procesor) a frekvence je az 1.6Ghz a vyssi L2 cache. floating point operace jsou pak i 10x rychlejsi. Na aplikace typu data warehouse je porad lepsi "klasicky" SPARC64 s vyssi frekvenci; nicmene porad je zde moznost volby, ktery server vybrat pro konkretni aplikaci na stejne architekture. viz. napr. tento blog

[RoJ]

Vskutku castecne. Jinak je v single-thread vykonu porad horsi, nez stara UltraSPARC-III na 1.2GHz. Nicmene proste to je o druhu prace. Web + DB backend je proste to, na co je T-rada delana. Mraky kratkych dotazu. Takze CPU se stejne flaka protoze tu cte ze site, tu posila na sit, tu cte z disku, tu zapise, vykonu netreba, je treba neztracet cykly cekanim a nezdrzovat tak frontu.

Vetsi zlepseni v T2 je fakt, ze kazde jadro ma dve instrukcni pipeline, pro kazdou ctverici HW threadu jednu.

Ale porad, pokud mate load a/nebo context switche na starsich cpu nizke, tak T2 nevyuzijete. Na zakladni prehled, jestli vase aplikace je vhodna na T radu CPU maji SUNove "cooltst", skript pro pouziti na Solarisu a Linuxu, ktery vam sleduje zatez a podle par jednoduchych pravidel vyplivne odhad, jestli ma nebo nema smysl prechod na T procesory.

Jsou to dobre procesory, ale do serveru a na specifickou zatez. Web, sitove sluzby, myriady kratkych transakci. Kdo nevidel, neoceni.

[Michal Kubeček]

Otázkou je, jestli to vůbec mají v úmyslu dohánět. Většina x86 procesorů je v počítačích, kde by se něco takového ani zdaleka nevyužilo. Připomíná mi to jeden článek, kde autor tvrdil, že hlavní problém architektury K10 spočívá v tom, že marketing neuhlídal inženýry a nechal je, aby sobě pro radost navrhli výborný serverový procesor, který se ale prodává jako desktopový…

[cthulhu]

v casech konsolidaci, virtualizaci a naslednych uspor na misto a chlazeni v datacentrech jsou vypocetni naroky na 1U cim dal vyssi. Co se tyce x86 PC, tak vetsine uzivatelu by levne dvoujadro v kombinaci s rychlym SSD diskem udelalo daleko lepsi sluzbu nez mamuti quad core. Ale nyni je holt takova doba - vic jader, vic adidas.

[vlk]

na i7 je to velmi podobne, ale HT sa tam predsa len trocha podpisal... a to, ze ked kompilujem na -j 8 (aj viac) tak nikdy sa nevytazia vsetky jadra na maximum, stale je to asi na 90 - 95% zrejme je to koli zdielanej L1 a L2 cache, ktora je vzdy pre dvojicu HT jadier.

a co som skusal, v pripade core quad a -j 4, su vytazene vsetky jadra v priemere na 99%

[kralyk z abclinuxu]

Zajímavé je, že časy se liší, ač ne o mnoho, už když j se blíží počtu cores, ale není větší.
Např. 4- a 8-jádro je výkonější než 2-jádro už při -j2 (přitom procesor je furt ten samej).
Stejně tak 8-jádro je výkonější než 4-jádro i pří j<8.

Vysvětluju si to tím, že na více jádrech méně překáží kernel, systémové procesy atd, prostě všecky ty ostaní procesy. Nebo je to něčim jiným?

[Kvakor]

Ne, myslím, že je to přesně tak, všechny asynchronní vlákna jádra, co zajišťují I/O (třeba pdflush), mohou běžet na volných procesorech, takže nejen že neubírají procesorový část uživateslkým procesům, ale ješte se ušetří režie přepínání úloh na procesoru (uložení a načtení všech registrů, prohozeni TSS+LDT a pod.).