Perl 6 - the future is here, just unevenly distributed

IRC log for #divine, 2015-02-08

| Channels | #divine index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
02:47 ilbot3 joined #divine
02:47 Topic for #divine is now DIVINE: A Parallel LTL Model Checker (http://divine.fi.muni.cz) | http://irclog.perlgeek.de/divine/
11:50 msabo joined #divine
12:25 xstill hm, ale to, že divine se shared bere víc paměti na stav pokud běží na víc vlánkech je dost divné, až se mi tomu nechce věřit
12:42 mornfall a nemá třeba v průměru delší frontu?
12:42 mornfall navíc teda alokace má nějakej per-thread overhead (i když snad ne moc velkej)
12:43 xstill to mě taky napadlo, ale lokální fronty jsou max 64 zdá se
12:43 xstill i když ona vlastně může být globální fronta delší
12:43 mornfall jo to jsem myslel
12:43 xstill já v té statistice nemám délku front (to je možná chyba)
12:43 mornfall možná je
12:55 xstill ale je tam řádově míň stavů než v hashtabulce (cca 30x)
12:55 xstill navíc teda ta fronta je v podstatě jen deque pointrů
12:55 mornfall tak já nevim co znamená „víc paměti“ :)
12:55 mornfall 5%? 10%? 200%? :-)
12:56 xstill tak zhruba to, že mi to teď na auře s 500k stavy bere víc než na lokále s 20M stavy (32 vs. 4. vlákna)
12:57 xstill (aura 4GB rss, lokál 3GB)
12:57 xstill takže hodně
12:57 mornfall ten stejnej model jo?
12:57 xstill jo (doufám)
12:57 mornfall to je 40x víc RAM na stav?
12:57 mornfall to vypadá trochu jako bug :P
12:58 xstill no to docela jo
12:58 xstill no a aby toho nebylo málo tak mi to na auře zesegvilo
12:58 mornfall asi bych začal tím že bych si nechal vypsat statistiky z poolu
12:59 mornfall jaj
12:59 xstill mám ale core
12:59 xstill jen je to teda release
13:00 xstill a musím si vytáhnout gdb z antey asi protože to na auře to nedává
13:17 spito hmm, to skoro vypadá, že je něco úplně hodně blbě
13:27 xstill strašně
13:27 xstill ještě vědět co…
13:35 xstill hm, zesegvilo to uvnitř new v Lake::Wharf::newblock
13:40 xstill hm, proč to volá malloc/free z libmpi
13:40 xstill na mě to skoro dělá dojem, že to mohl být race v alokaci
13:42 mornfall no, to by segvilo skoro kdekoliv jinde než v new
13:42 mornfall (pokud to není race v TBB mallocu...)
13:44 xstill no, to jsem myslel, v tom okamžiku volaly 2 vlákna free a 2 malloc, ale divné je, že podle gdb je ten malloc z libmpi a ne z tbb
13:45 mornfall hm, jakože všechny malloc-y jsou z libmpi?
13:45 mornfall to by mohlo lecos vysvětlovat
13:45 mornfall (mj. i proč to normálně nevídám(e) ... většinou mám buildy bez mpi)
13:45 xstill jsou
13:45 mornfall jo, mpi není threadsafe
13:45 mornfall takže ....
13:46 xstill cože?!
13:46 mornfall teda některý implementace maj threadsafe mód ale nezapínáme ho
13:46 mornfall jak cože :)
13:46 mornfall proč myslíš že máme dedikovaný MPI vlákno...
13:46 xstill nevím, očekával bych docela, že MPI bude threadsafe
13:50 xstill teď teda jak z toho ty mpi věci dostat
13:50 xstill a ještě je zajímavé, že a akre stejný build (zdá se) nepadá
13:50 mornfall no, ono to normálně nealokuje tolik
13:50 mornfall asi
13:51 xstill no je možné, že se to projeví až při hodně moc vláknech
13:56 xstill ono je potom klidně možný, že za to za všechno může MPI včetně toho kolik to žere paměti
13:58 mornfall to úplně nevim, ale asi bych to zkusil bez něj :-)
13:58 xstill hm, ale on tam nějakej rozdíl je i u mě na buildu bez mpi
13:58 xstill ale zatím nemám moc stavů
13:59 xstill tak to může být i poolem (jako že celkem je tam pod 1G paměti)
13:59 xstill ale třeba je to fakt blbě no
14:11 xstill no tbb malloc zdá se moc nefunguje, teda nevolá se ani když tam není mpi
14:15 xstill nojo
14:19 xstill mornfall: viz patch
14:19 xstill asi to teda neřeší situaci kdy je mpi a není tbb (zatím)
14:23 mornfall haha dobrý no
14:35 xstill mornfall: dokážu se nějak ze statistik dostat k poolu?
14:36 xstill asi ne co…
14:40 xstill zjistil jsem totiž že lokálně mi to jednu chvíli žralo 1G RSS a pak to skočilo na 700M a teď na 250M tak by mě zajímalo, kde se to válelo
14:42 xstill což může být rozdíl nějakejch 300 bloků v poolu, to by nebylo nemožný asi
14:44 xstill hm, pool bloky nikdy nedealokuje?
14:49 xstill a teda nejsem schopnej lokálně reprodukovat ten mpi malloc, prostě tam není ani když vypnu tbb
14:51 xstill hm ad ta paměť, to by chtělo vědět jak to vlastně systém přiděluje ty bloky, sem si uvědomil, že se to rss mohlo zmenšit protože jsem vedle toho běžel kompilátor, kterej mohl vyžrat dost paměti (jako zůstalo to stabilně dole, takže se nejspíš odswapovala jen nepoužívaná paměť). Každopádně je to docela nepříjemný, že je tam takovej ovehead.
15:08 xstill proč jsou vlastně free-listy na každou velikost?
15:12 xstill a vygenerovat 400k stavů bez jediné alokace je taky dobré :-)
15:22 xstill mornfall: ono vůbec, proč se v poolu preferuje alokovat další pointer z freelistu místo z částečně zaplněnýho bloku?
15:25 xstill navíc nevím jestli by nebylo lepší mít jen 1 globální freelist  a ne na každou velikost
15:26 mornfall jako že by alokace byla O(n) místo O(1)?
15:26 mornfall to by mohlo dost bolet
15:26 xstill proč by měla být O(n)?
15:26 mornfall protože bys musel hledat ten správnej chunk přes celej freelist?
15:26 mornfall navíc by se musel zamykat celej
15:27 xstill hm, a nesjou všechny free bloky v principu stejný?
15:27 mornfall jaký free bloky?
15:27 xstill tak bloky co jsou v freelistu
15:27 mornfall ve freelistu nejsou bloky
15:27 mornfall to by nedávalo smysl
15:28 xstill aha
15:28 xstill tak to jsem dost zásadně nepochopil no
15:28 mornfall free uvolňuje objekty ne celý bloky
15:29 mornfall kdybys musel uvolňovat po blocích tak neuvolníš nejspíš nikdy nic
15:29 xstill tak pak to hle dává smysl
15:29 xstill *tohle
16:53 xstill tak statistiky v poolu říkaj, že po prohledání 100k stavů je celkem v poolu 80 MB alokací, z toho 30 MB wasted (na jednom vlákně, protože to je ze simulate, ale to by nemuselo vadit)
17:12 xstill a na auře při 100k stavech brala verifikace už 5GB paměti, to nejde úplně svést na pool řekl bych (u mě to bylo určitě pod 1GB) i kdybych počítal, že bude 30MB wasted na vlánko tak je necelé giga, takže 3 ještě někde běhaj
17:13 mornfall hm, chtělo by to udělat nějakej SIGUSR1 handler kterej by vypsal pool dump a jel dál
17:14 xstill no to by možná šlo, každopádně to teď zkouším na menším modelu nechat doběhnout verify, tak uvidím co najdu
17:14 mornfall jj
17:16 xstill zatím se zdá, že wasted škáluje s počtem vláken (17k stavů: 1 vlákno: 33M wasted, 2: 57M, 4: 110M)
17:25 xstill jako nesedí to: http://pastebin.dqd.cz/2tS5/ (ta statistika je poslední sample)
17:26 xstill v rss zdaleka není tolik co pool říká a ve vm je naopak 2x víc u těch 32 vláken
17:27 mornfall to je docela zajímavý
17:27 mornfall jak se to stane...
17:29 xstill to kdybych věděl
17:29 mornfall máš někde celou tu statistiku z poolu?
17:29 xstill jo
17:30 xstill http://pastebin.dqd.cz/J2yB/
17:30 xstill ale není na tom nic moc divnýho
17:31 xstill teda jako možná by mě i zajímalo, co je v těch nedealokovaných velkých blobech, ale je jich málo
17:32 mornfall no to je stav llvm interpretu
17:35 mornfall (asi)
17:39 msabo joined #divine
17:50 xstill wtf. ona se nám docela hýbe baseline hodnota co se od toho odčítá podle počtu vláken, to ovšem nechápu, protože tak se určuje v konstruktoru statistik, než všechno nastartuje
17:50 xstill docela = o 150MB mezi 1 a 32 vlákny
17:51 mornfall no, 32 vláken to máš 320M zásobníků (VM) třeba
17:52 mornfall hm, nebo se to počítá než nastartujou ty vlákna?
17:52 xstill mělo by
17:52 xstill pokud jsem něco strašně nepřehlédl
17:53 xstill ale těch 320M zásobníků je i tak dobrá připomínka
17:55 mornfall ono toho bude trochu víc, ale asi už ne o moc
17:57 mornfall no a teda makeGlobal* se volá až po select()
17:57 xstill jo na to jsem právě přišel, že to alokuje select
17:58 xstill aha jasný
17:58 xstill on musí alokovat tabulky a interpretry a tak
17:59 mornfall jj
17:59 xstill tak pak to sedí, to co jsem změřil, v VM byl rozdíl cca 800M z toho 490M byl pool a cca těch 320M vlákna
18:00 xstill ale asi bysme měli vyhodit tu baseline, protože to zamlžuje výsledky
18:00 xstill nebo to vypsat jako první řádek
18:00 mornfall no, asi by se to mělo počítat před selectem, ale to znamená že se to musí udělat nějak úplně jinak
18:01 mornfall když baseline vyhodíš tak zase bude hrozně záležet na velikosti binárky všechno
18:01 mornfall možná by to šlo dát konstruktoru statistik jako parametr
18:02 xstill hm, no ono toho se nezbavíš, jak jsem to krokoval tak jen parsování commandline nějak vygenerovalo 100M paměti, počítám že tím že se natáhly kusy binárky
18:02 mornfall no ne, VM obsahuje binárku celou hned od začátku
18:03 xstill aha jo
18:03 mornfall parsování počítám něco alokuje takže to může být TBB který si vygeneruje struktury a zarezervuje něakou paměť
18:03 mornfall +j
18:05 mornfall ono by mohlo všemu trochu pomoct kdyby si pool ty bloky bral anonymním mmapem rovnou od kernelu a ne skrz 3 vrstvy malloc-ů
18:05 xstill :-)
18:07 xstill jako ještě mě napadlo, jesli by nemělo smysl si na každém Wharfu držet seznam úplně prázdných bloků a pokud chci alokovat tak místo toho most šáhnout tam. To by ani nemuselo brzdit, vzhledem k tomu, že všechny ty mallocky nebudou moc rychlý asi.
18:08 mornfall to by asi šlo pokud dokážeme poznat že nějakej blok je prázdnej
18:09 xstill to bych musel zjistit
18:09 mornfall ono to asi nepůjde
18:10 mornfall to by si musel blok pamatovat kolik se toho uvolnilo a to by se o to vlákna furt prala
18:11 mornfall spíš by bylo reálný udělat nějaký GC který by se občas spustilo
18:11 xstill hm, bloky nejsou thread-lokal?
18:11 xstill aha freelisty
18:12 mornfall tak
18:12 mornfall a to bys ty freelisty musel všechny opravit kdybys chtěl ukrást volnej blok
18:12 xstill nojo
18:12 mornfall (teda odpovídající velikosti)
18:12 xstill navíc ještě, achjo
18:15 mornfall no není to jednoduchý, si nemysli že jsem to zase úplně odflákl :P
18:19 spito heh, jak to je s tím shared - mnůžu za to já?
18:20 mornfall nepochybně :P
18:28 xstill co se shared?
18:31 spito mornfall: děkuju, to pomohlo
18:32 mornfall kdykoliv
18:42 spito xstill: už tušíte, kde je zakopaný pes? (teda jestli jsem dobře pochopil, tak problém je v moc alokované paměti)
18:46 xstill spito: těžko říct, to co jsem změřil u sebe smysl dává (může za to částečně pool a částečně zásobníky vláken), ale na té auře byla odchylka podstatně větší (jen jsem tam ještě nedělal detailní analýzu po všech těch patchcích)
18:48 xstill mornfall: mrkneš na ty patche?
18:51 mornfall už mrkám
18:56 xstill dík

| Channels | #divine index | Today | | Search | Google Search | Plain-Text | summary