Perl 6 - the future is here, just unevenly distributed

IRC log for #divine, 2014-06-28

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

All times shown according to UTC.

Time Nick Message
01:47 ilbot3 joined #divine
01:47 Topic for #divine is now DIVINE: A Parallel LTL Model Checker (http://divine.fi.muni.cz) | http://irclog.perlgeek.de/divine/
09:34 mornfall [11251.640303] Kernel panic - not syncing: Out of memory: compulsory panic_on_oom is enabled
09:34 mornfall takhle to dopadlo s 64b release fedorou
09:34 mornfall ostatní vypadají výrazně líp
09:38 mornfall xstill: horší je, žes asi vyrobil deadlock v owcty-shared
09:38 mornfall Running shared/owcty-shared.sh ...              building of `/nix/store/wgd05hj3l8szgyjqabj0yw3m983cdjsc-divine-timed-3.0.92+pre4848.drv' timed out after 3600 seconds of silence
09:38 mornfall (skončilo tím docela dost buildů)
09:38 xstill hm, super
09:40 mornfall a navrhuju dát tomu nested-dfs normální full atomic aspoň na chvíli, protože jinak než hydrou to asi nedokážu reprodukovat abych to otestoval, nebo se aspoň podíval na trace...
09:41 xstill teď to nechápu
09:41 mornfall no, jako DataWrapper nastavit std::atomic
09:41 mornfall na windows furt padá nested-dfs, s weakatomicem
09:42 mornfall chtěl jsem to otestovat takhle lokálně, ale nespadlo mi to ani bez atomicu ani jednou
09:42 xstill no můžeš to zkusit
09:42 xstill já se podívám proč jsem rozbil owcty
09:45 xstill asi bysme si fakt měli dát závazek, že přes léto zverifikujeme shared visitora
09:47 xstill ono by to asi šlo pokud bysme si napsali testovací genrátor, kterej bude generovat pevně v kódu napsanej graf
11:08 xstill hm, kdybych alespoň viděl na kterém testu to zdechlo
14:05 xstill joined #divine
15:13 xstill mornfall: ten deadlock se mi nedaří reprodukovat, poslal jsem ti patch kterej přidá max-time do testů aby jsme viděli na čem to zdechlo
15:28 xstill jo, jenže ten deadlock je způsobenej tím, že se sice vyresetuje fronta ale ne termination
15:31 xstill což se stane přesně když se vyprázdní fronta v konstruktoru visitora
15:32 xstill zajímavý, že to schodilo jen owcty, asi proto, že nikdo jinej moc nedělá víc iterací
15:36 xstill ale je to divný
15:37 xstill protože to by znamenalo, že ta předchozí iterace nemohla zavolat terminate(), jinak by vynulovala terminátor. Ale potom měla doběhnout normálně -- kde se potom vzal ten bordel ve frontě?
15:39 xstill na můj vkus je v tom dost bordel
15:55 xstill je to čím dál tím vtipnější, teď mi zdechlo owcty na assert_die (řádek 147), kterej podle mě nemůže vůbec nastat
15:55 mornfall jestli máš zkorumpovanou heapu nebo zásobník, může se dít v podstatě cokoliv
15:56 xstill no to nevím jak bych toho dosáhl
15:57 mornfall to já taky ne, ale to neznamená že se to nestalo :-)
15:57 xstill zajímavý padá to dost deterministicky ale jen v releasu
15:58 mornfall ha, pravda
15:58 mornfall jedinej abort v debug máme User specified group tBoj10kqGOBlFR54DvVdtAHGcLPx2Arw is not available.
15:59 mornfall (aby toho nebylo málo... jak se to kruci může stát?)
15:59 mornfall takže jo, release padá docela pravidelně a debug vůbec
16:01 xstill hm, valgrind mi nic neříká (a nepadá to v něm úplně pořád)
16:02 xstill kde byla ta grupa?
16:02 mornfall pheme02
16:03 mornfall na čem to zkoušíš? (resp. na čem to padá?)
16:03 xstill test/data/test4.dve (owcty, shared, -w 2)
16:03 xstill --no-reduce
16:05 xstill a ten assert se začal objevovat po té co jsem vyresetoval terminate spolu s čištěním fronty
16:05 xstill (ne že by to s touhle informací dávalo větší smysl)
16:07 mornfall nezůstává ti někde běžet nějaký vlákno z předchozího výpočtu?
16:11 xstill při tom abortu běží jen master, ale co se děje při té konstrukci visitora to nevím jak zjistit
16:12 mornfall Jun 28 00:27:14 pheme02.fi.muni.cz dsched[27142]: [128B blob data]
16:12 mornfall co to může znamenat?
16:12 xstill že mi chybí \n na konci nejspíš
16:13 xstill (je to fakt šikovný ten journalctl…)
16:15 xstill kapku problém je že create-group --hold nic neloguje, takže nevíme kde skončil
16:15 mornfall -a: Jun 28 00:27:14 pheme02.fi.muni.cz dsched[27142]: [buildfarm] You have now 3.86GB limit for memory and can use 1 cpus.
16:15 mornfall Use 'dsched-change -m <memory> -c <cpus>' to change limits.
16:15 mornfall (nechybí, je tam navíc :-)
16:17 xstill super
16:18 mornfall hm
16:18 mornfall ale je to divný, protože tu groupu vytvoří dsched[26952]
16:18 mornfall teda, zavře
16:19 mornfall ale vytvoří ji 26953 podle všeho?
16:19 mornfall aha ne, on jen create-group nic neloguje
16:20 mornfall stejnÄ› tomu moc nerozumim co se tam stalo
16:24 mornfall xstill: jak často to owcty padá, a máš zaplý performance?
16:25 xstill no často, ale ne v té verzi která je v mainline
16:25 xstill asi mám performance
16:29 mornfall víš o tom že ApproximateCounter::reset nevyresetuje local?
16:31 mornfall (jen teď nevim jestli to je naschvál nebo je to bug)
16:31 xstill ne, ale spíš jsem si všimnul toho že clear() na lockedqueue nikdy neresetovalo termination
16:31 xstill což mi příjde trochu divný
16:32 mornfall já myslim že ten hlavní bug je že se data nesmažou a nevyrobí nový mezi iteracema :-)
16:33 mornfall resp. je potřeba je nějak kompletně vyresetovat
16:33 mornfall s tím že se bude cokoliv z visitora přenášet mezi iteracema se nikdy nepočítalo
16:33 xstill hm, a nezaváděli se data přesně kvůli tomu aby přežili mezi iteracema?
16:33 mornfall ne
16:34 mornfall zaváděli se přesně kvůli tomu aby je šlo sdílet mezi vláknama :)
16:34 xstill aha
16:34 mornfall (teda aspoň doufám :-)
16:35 mornfall jo, je to tak... ale nejde to jednoduše řešit tím že se zmažou, bude to chtít reset()
16:35 mornfall smažou*
16:36 xstill já se v tom pěkně potám, už jsem to vylepšil na SEGV
16:36 mornfall (Data je jen balík pointrů kterej se rozkopíruje mezi worker instance algoritmu, a když se tak stane už není cesty zpět, ty vlákna na sebe „nevidí“ aby si mohly vyměnit nový pointry -- to je ten důvod proč existujou)
16:37 mornfall takže z konstruktoru Implementation bych clear/reset přesunul do novýho Data::reset()
16:37 mornfall který se bude volat Algorithm::visit než se zkonstruuje novej visitor
16:37 mornfall a je teda potřeba vynulovat aj ty local
16:38 xstill ha, segv objasněn, ono d.terminator.reset() a d.terminator->reset() je dost rozdíl, přesto, že se obojí zkompiluje
16:38 mornfall :D
16:38 mornfall d.terminator->reset() je ale furt blbÄ›
16:38 xstill jo, a proč že je nejde jen smazat
16:38 xstill ?
16:39 mornfall no, není jasný jak je updatovat ostatním vláknům
16:39 xstill jo to už chápu, že je to furt špatně
16:39 mornfall problém: potřebuju aby každý vlákno mělo pointer na nějakou sdílenou strukturu (chunkq, etc.)
16:40 mornfall řešení: na začátku výpočtu (konstruktor algoritmu) se vyrobí sdílený struktury a pointry se rozkopírujou všem workerům
16:40 xstill aha chápu, nemůžeš to zrušit protože už nemáš jak to distribuovat
16:41 mornfall hmm
16:41 mornfall ale visit() zná typ algorithmu (Self)
16:41 mornfall jenže to mi je platný, stejně nemá ukazatel na mastra
16:42 mornfall wait
16:43 mornfall ale mohlo by to jít
16:43 mornfall self->topology().distribute, třeba
16:43 mornfall jen teda visit() je už pozdě, protože to běží paralelně
16:44 mornfall kruci kruci :-)
16:46 xstill jo a ještě je problém, že by bylo potřeba smazat všechny local v terminate, ne jen ten v místním vláknu, ne?
16:53 mornfall no, když si ho smaže každý samo tak je to jedno
17:30 xstill jo, a navíc local už se resetuje teď protože Termination se konstruuje s visitorem, zůstává jen Termination::Shared
17:31 xstill ale proč to potom nefunguje když vyresetuju termination to nevím
17:38 mornfall ah
17:38 mornfall pravda
18:43 xstill hej, to nemohlo nikdy fungovat protože visit běží paralelně, tudíš konstruktor visitoru běží paralelně a tudíš zatímco jeden už nacpal iniciální vrcholy do frony, druhej ji jde mazat
18:43 xstill bude potřeba aby ten reset udělal master nějak
19:01 mornfall jo, no :-)
19:02 mornfall asi Algorithm::parallel to bude muset řešit
19:03 xstill no to mě taky napadlo, jenže to ne vždycky pouští něco co volá visit
19:04 mornfall to zas tak moc nevadí
19:04 mornfall řekl bych že parallel ty data vytvoří a zase zahodí
19:04 mornfall tzn. že mimo parallel budou ty data vždycky null pointry
19:05 xstill hm, to snad Å¡lo

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