Kolik jobs pro make? (diskuse)

[belisarivs]

Jak jsi dosel k tomu narustu na -j16 ve druhem grafu? Nejak divne to prokladas.

Nebo jsi delal i testy s -j8-16?

[fakenickname]

Omlouvám se, špatně jsem nastavil gnuplot. Chyba opravena, díky za upozornění.

[belisarivs]

V pohode. Zajimavy pokus.

[cadic]

počet jobů by teda měl bejt takovej, do kolika vláken se kompilovaná věc dokáže rozložit, ne? :)

[fakenickname]

Pro nejrychlejší kompilaci ano (parametr -j bez čísla nastaví neomezený počet podprocesů), ale poté může být problémem omezení počtu procesů v systému či dostatek volné paměti.

[fakenickname]

A vzhledem k tomu, že zisk od n*2 dál je velmi malý, nemá více podprocesů zřejmě smysl.

[Feco]

Off topic - ako sa da pracovat v DWM s GIMPom? Skusal som a je to bieda... Inac by som nemal na DWM nijake namietky...

[Marek Bernát]

Dwm je skvelý wm, ale spolieha sa na to, že aj programy budú podobne skvelé a nebudú nikomu nútiť, ako si má rozostaviť okná. Bohužiaľ to nie je často splnené, takže tu máme na to float. Proste odfloatuj gimp na nejakú plochu a tam ho môžeš používať úplne rovnako ako všetci ostatní.

[fakenickname]

dwm config.h umožňuje přidat do static const Rule rules[] například následující pravidlo:

  { "Gimp",     NULL,       NULL,       0,            True,        -1 },

což způsobí, že se gimp bude spouštět vždy s přepnutím na plovoucí rozložení. dwm je totiž dynamický wm. Kromě tiling a floating módu však obsahuje ještě monocle (podobné ratpoison) a pomocí malinkého patche si můžeš třeba dodat vertical tiling (bstack patch). A pozor na jednu věc - dwm nemá jako wmii nebo jiné dynamic wm možnost používat tiling a floating vrstvy najednou, buď je kompletně celý wm floating nebo tiling (přepíná se pomocí zkratek)

[Marek Bernát]

To nie je úplne pravda. Napríklad okná s hintom TRANSIENT sú floating (logicky) aj keď si v tiling móde. A v prípade potreby je triviálne napísať patch (alebo možno aj existuje), kde budeš mať zoznam aplikácií, ktoré sa na danej ploche majú floatovať (tak to má napríklad xmonad). Dokonca mám pocit, že tak to aj v dwm kedysi bolo, ale už som ho rok nevidel, tak je to teraz možno inak.

[Marek Bernát]

Len pre budúcnosť: keď máš graf, kde 99% plochy zaberá prázdne miesto (v zmysle, že je rozdelený na dve časti a jedna z nich je taká), je rozumné závislosť prehnať logaritmom. Takto z toho veľa nemám, nevidím poriadne ani rozdiely medzi malým počtom jobs (kde sú najvýraznejšie), ani medzi veľkým počtom (kde sú pomalé). Ak sa ti s tým, ešte chce pohrať, mohol by si to skúsiť, stačí zadať "set log y" a ak to bude stáť za to, postni to sem znova. Dík.

[fakenickname]

Logaritmické měřítko jsem samozřejmě zkoušel hned na začátku, ale nedařilo se mi získat nějaký hezký výstup, tak jsem použil klasické konstantní. Navíc s gnuplot zas tolik neumím

[Marek Bernát]

V poriadku. Len pre istotu som na to upozornil, lebo s grafmi neskúsení ľudia robia veľa vecí, ktoré sú jednak neestetické a jednak sa stráca veľa informačnej hodnoty.

[Marek Bernát]

Btw, je pravda, že s tým logaritmom som sa silne sekol, tvoja závislosť je typu 1/x a po aplikácii logaritmu sa z nej rozhodne nestane priamka S tým sa toho moc robiť nedá (viď "plot 1/x"). Aspoň mňa teda nič rozumné nenapadá, ale možno niekto poradí

[Jary]

Hehe, my, co máme jedno jádro nemáme problém a nastavujeme bezmyšlenkovitě -j2.

[Jary]

A dělal jsi něco jako flush-all-caches před každým měřením? Protože jestli ne, tak tvrdím, že výsledky, ač pěkné jsou dost k ničemu.

[Jary]

Ještě dodám, že jsem nelenil a zeptal se googlu a google řekl, že odpověd mám hledat v linux-mm.org/Drop_Caches. Z toho článku bych vyvozoval závěr, že před každým testem nejlépe dělat

sync
echo 3 > /proc/sys/vm/drop_caches

[fakenickname]

Nikdo Vám nebrání provést podobné měření s mnohem větší přesností.

[A]

+1

[Jary]

Není až tak pravda. Brání mi v tom lenost. Respektive jelikož nevlastním vícejádro, nemyslím, že mi znalost toho, jestli jde o j=2*p, nebo j=p+1 momentálně bude k něčemu dobrá a tak se nebudu namáhat.

Jestli jsem urazil tak pardon, nebylo to tak míněno a příště se pokusím vnzášet námitky méně arogantně.

[Bilýgr]

Tvů komentář je v pohodě, nemáš se zač omlouvat. V pohodě totiž není autor zápisku - to se ví dlouho (nezapomenutelná je histerická scéna, kterou jednou ztropil, protože mu lidi nepřipisovali jeho zásluhy za jednořádkovou konfiguraci conky, che). A už to stihnul ukázat i v této diskuzi (viz "příště si to nechá pro sebe"). Kdyby bylo po jeho, tak by zde byla diskuze zakázaná, aby nikdo nemohl na nedostatky upozornit...

[fakenickname]

Tímto komentářem jsi mě přesvědčil, že abclinuxu je místo, kam už nikdy nepáchnu.

[Martin]

Fakt sorry, ale nemohl jsem si pomoct. Jak nervní asi musí být člověk, když se nechá takhle trapně vytočit anonymem? Co teprv když ho nasere někdo skutečný v reálu? To pak teprv musí bejt mazec.

[Bilýgr]

Pravda bolí stejně od anonyma jako od kohokoliv jiného, nemyslíš? A že to pravda do puntíku je, tak za tím si stojím. A pokud to nevíš, tak to byl on, kdo do bugzilly přidal požadavek na možnost zakázat komentáře.

[A]

Daj link na tu hystericku reakciu ohladne toho conky...

[Samae1]

Co je špatného na možnosti zakázat komentáře, pokud se o tom vede diskuze ? Pokud by na ABCL bylo 90% lidí jako vy(stal by se zněj idnes, nebo novinky v dobách své největší slávy), byl by to nutný krok.

[A]

Zase hysteria?

[Samae1]

Bohužel lidé jako on se vyskytují na každém alespoň trochu navšťevovaném portálu. Je to daň za svobodný Internet a jedinou cestou proti ní je zakázat reakce, bohužel s tím přijdeme i o ty kvalitní.

[Samae1]

Na tohle se dá snad říct jen jedno: A co jste udělal vy ?. Kvůli Vašemu ubohému chování přijde Ábíčko o jednoho člověka, který je ochotný se dělit o svoje zkušenosti. Přečtěte si třeba http://www.abclinuxu.cz/blog/Libitu/2009/7/deset-veci-ktere-s-vimem-nedelejte-2, autor získal vysoké hodnocení textu a spoustu pozitivních reakcí. Dnešní text má také poměrně hezké hodnocení(nyní 9 hlasů 100% ), týká se Linuxu a jistě se najde několik lidí, kterým se text hodí.

Co Vám vůbec vadí na "Nikdo Vám nebrání provést podobné měření s mnohem větší přesností. ", vždyť autor nereaguje nijak přehnaně. Pokud chcete dokázat, že autor "není v pohodě", mohl by jste uvést odkaz na hysterickou scénu(a i když ho uvedete, každý někdy udělal chybu ne? ). Takhle si musím myslet, že jste pouze závistivý anonym, který se za každou cenu snaží srážet ostatní kvůli předchozím sporům. Na takovéhle lidi patří pouze jediná věc - nekrmit.

[deda.jabko]

casto se uvadi jako dobra volba (2*n + 1), ale zalezi na typu ulohy. zavisi to na tom jak moc intenzivni jsou vypocty ... u nekterych vylozene intenzivnich uloh se mi zase osvedcila volba (n - 1)

btw. sveho casu jsem mel s parallelni kompilaci PHP problem, ze se program nesestavil korektne, funguji ty binarky?

[fakenickname]

Nezkoušel jsem.

[Marek Bernát]

Možno mi niečo ušlo, ale podľa tých grafov je čas dokončenia úlohy klesajúci s n (v rámci chyby merania, ktorá nie je uvedená, ale nejakú som si tam domyslel), tak prečo nenastaviť rovno maximum, povedzme 10000?. Z tých grafov predsa nevyplýva, že keď nastavím 2*n + 10, alebo 4*n, tak to bude horšie, práve naopak, je tam ešte pokles.

[deda.jabko]

tak prečo nenastaviť rovno maximum, povedzme 10000

na to jsou dve odpovedi...

jednak to asi nema smysl ... amdahl's law je priserna bestie a jde to videt i z tech grafu... od urciteho budu to zlepseni je absolutne nevyznamne.

za druhe, tady v techto grafech to nejde poznat... ale s postupem casu by se tam objevil pokles vykonu, ktery je zpusobeny tim, ze udrzovani X procesu uz bude mit takovou rezii, ze se nevyplati vic paralelizovat.

[Marek Bernát]

To zlepšenie je bezvýznamné, ale aký má význam hádať sa o 2*n + 47 a 3^n - exp(n) + 1, keď to najlepšie riešenie je aj tak asymptotické?

Ten druhý bod to trochu vysvetľuje a presne také niečo som si aj myslel, že to bude overhead. Ničmnej, skutočne to v tých grafoch nevidím a ako také nemajú o dôkaze 2*n žiadnu vypovedaciu hodnotu. To, čo popisuješ ty, by bol totiž graf s minimom niekde okolo 2*n (n-1, whatever) a nie čisto klesajúci graf (modulo chyba merania). Lenže, aj tak je to zjavne závisle od toho, kde to použiješ (konkrétny program, ktorý sa prekladá), takže jaký to má zmysel? Keď už ten make spustíš raz, tak dostaneš správnu binárku a si hotový. Načo ho spúšťať znova a testovať, či by sa to nedalo vybuildovať o sekundu rýchlejšie? A ďalej, skutočne to riešenie, nastaviť proste n = 10000 je až tak zlé? Ak je to tak, že sa o moc tá asymptotická hodnota nelíši od minima, tak nie je dôvod skúmať nejaké závislosti a nastavovať to pre každý program zvlášť, najrozumejšie je zobrať raz a pre vždy n = 10000 a človek je vybavený. Fakt mi to pripadá ujeté

[deda.jabko]

To, čo popisuješ ty, by bol totiž graf s minimom niekde okolo 2*n (n-1, whatever)

ja jsem taky psal, ze to zalezi na typu ulohy a vetsina techto hodnot se nastavuje/odhaduje empiricky. mam napr. zkusenost s ulohami kde se ciste pocita je dobre se drzet kolem toho n... pokud se na neco musi cekat napr. diskove I/O, sit, jiny proces, je dobre mit pocet procesu vetsi.

Ak je to tak, že sa o moc tá asymptotická hodnota nelíši od minima, tak nie je dôvod skúmať nejaké závislosti a nastavovať to pre každý program zvlášť, najrozumejšie je zobrať raz a pre vždy n = 10000 a človek je vybavený.

to neni dobry napad. kdyz seberes hodnotu n = 10000 takovy vypocet ti sebere vyrazne vic zdroju (napr. RAM) nez kdyz bude n = 100 a realny uzitek bude srovnatelny.

[Kvakor]

Ano, i když bude velké část paměti sdílená mezi procesy, zásobník, hlada a statická data sdílená neboudou, takže budou ujídat z volné paměti, která by mohla byt využita pro cache. A pokud poklesne cache pod určitou hodnotu, výkon půjde rapdině dolů.

[Marek Bernát]

Aha dík za ozrejmenie, ale vôbec do toho nevidím a z blogpostu som to nepochopil. V tom prípade ale treba skúmať nie len zaťaženie CPU, ale aj zaťaženie RAM, ak chceme objektívny výsledok a tento blogpost bol tým pádom ešte viac na nič

[fakenickname]

Moje měření mi zodpovědělo otázku zda je nesmysl používat více jobs pro make než je počet fyzických jader procesorů. Rozhodl jsem se o měření podělit, protože jsem myslel, že se někomu budou líbit reálně naměřené hodnoty. Zdá se, že další experimenty si raději nechám pro sebe.

[Marek Bernát]

Ty asi na konštruktívnu kritiku veľmi neveríš, čo?

[fakenickname]

Tak jsem právě udělal malý pokus. Stáhl jsem linux-2.6.30.4, rozbalil a spustil "time make -j". Tedy nechal kompilovat jádro s neomezeným počtem procesů. Následující hodnoty jsou hodnoty, které mi htop občas zobrazil přes ssh.

# procesu,  obsazeno RAM, obsazeno swap, load avg za posledni minutu
  1100         1800            300             ?
  1672            ?              ?             ?
  1436          700            200             ?
  2555            ?              ?           855
  2666         1942            670           899
  2846         1931            433           428
  3977         1726            953           568
  3652         1938           1493           469

Čas jsem nezaznamenával, kompilace probíhala něco přes 25 minut. Pak se na obrazovce objevilo několik hlášek "Out of memory: kill ... (make)" tak jsem to vzdal. Od počátku kompilace kontrolka disku ani jednou nezhasla. IMHO i kdyby kompilace dopadla úspěšně, trvala by s takovým chováním disku několik hodin (normálně kolem 30 minut). Stále zastávám názor, že nejvhodnější je n*2.

[Marek Bernát]

Tak toto je zaujímavé, dík. Keby sa ti nejako podarilo zmerať aj tú záťaž pamäte + čas pri -jX, tak to by bolo super. Ja osobne to totiž na starom jednojadre asi nezmeriam, ale aj tak by som bol zvedavý, ako sa to chová

[xkucf03]

Zajímavé by právě bylo dotáhnout ten test do konce – najít bod, kdy se to začíná lámat* a režie žere více než je mezní užitek z dalších vláken.

*) těch 89.910 → 90.142 nepovažji za zlom, ale spíš chybu měření.

[Kvakor]

Já na určení bodu, kdy už nemá cenu spouštět další procesy, používám jednoduchou metodu - přidávám procesy tak dlouho, dokud není čas v idle a iowait nulový (na obrazovce top je to čtvré á páté číslo). Většínou je výsledek opravdu dost blízký dvojnásobku počtu jader plus něco, i když záleží na poměru výpočty/I/O - čím víc I/O a čím pomalejší disky, tím víc procesů navíc.

[Roman Schulz]

Na 8 procesorovém serveru jsem pro kompilaci používal nejdříve -j2, potom pro urychlení jsem dospěl přes -j4 postupně až k -j8. Ale po tvém zápisku jsem zkusil dvojnásobek, tedy -j16 a vážně se čas kompilace zrychlil o další polovinu. Díky za tip

[Zdeněk Štěpánek]

Doted jsem razil zasadu N+1, ale zrejme prejdu na 2N.

Diky za zajimavy zapisek.

Zdenek

[Mrkva]

No přece 42! Jak o tom někdo může pochybovat?