| Time |
Nick |
Message |
| 04:30 |
|
xhire_ joined #divine |
| 04:34 |
|
zbeasnyy joined #divine |
| 08:24 |
xstill |
(toho midase potvrdím až bude online) |
| 13:40 |
mornfall |
xstill: TrackStatistics nejde přeložit? |
| 13:40 |
mornfall |
(s divine compile) |
| 14:48 |
mornfall |
xstill: co, pošleme Alexandrovi divine.bc? :-))) |
| 15:35 |
mornfall |
teď jsem teda ovšem trochu narazil |
| 15:44 |
xstill |
TrackStatistics nejde kvůli tomu, že zjištuje paměť (nějakej sys/*) |
| 15:44 |
xstill |
on je stejně irelevantní |
| 15:44 |
xstill |
kdo je Alexandr? |
| 15:45 |
mornfall |
viz mail |
| 15:46 |
xstill |
jo vidím |
| 15:46 |
xstill |
tak divine.bc je dost hardcore, tabulka možná míň |
| 15:47 |
xstill |
jsem vlastně chtěl zjistit jak je velkej divine.bc pro 1 vlákno a pak jsem na to zapomněl s těma bugama |
| 15:48 |
mornfall |
no, ale teda udělat GCable malloc nebude vůbec jednoduchý |
| 15:48 |
mornfall |
potíž teda je že v momentě kdy zjistíš že je pointer leaknutej tak už žádnej nemáš, aby ses podíval co byl zač |
| 15:51 |
mornfall |
musel bych přidat ještě jednu bitmapu do heapy asi |
| 15:53 |
mornfall |
a to se mi teda zrovna moc nelíbí... |
| 15:54 |
mornfall |
spíš by asi šlo ignorovat leaky celkově, ale to taky není kdovíjaký řešení |
| 16:11 |
xstill |
hm, tak jako tady to můžu vyřešit na úrovni modelu, nejspíš počítat reference, to není buhví co, ale fungovat by to mělo |
| 16:13 |
xstill |
tak s 1 workerem má divine.bc 30K stavů |
| 16:17 |
xstill |
hm, zrada, když mi darcs vyznačí konflikty a já udělám revert tak mi to smaže všechny konfliktní změny |
| 16:20 |
xstill |
to je ovšem tím, že jsem tam pushnul nedodělatný patche a pak pullnul upstream kterej měl jinou verzi |
| 16:48 |
mornfall |
takže se dvěma by to mělo být něco-jako miliarda? |
| 16:48 |
xstill |
asi… |
| 16:49 |
mornfall |
ale asi spíš výrazně víc, protože počítám že takhle to bere jako že všechen přístup do paměti je neviditelnej |
| 16:50 |
mornfall |
zkus jeden worker s tau+ bez taustores? |
| 16:50 |
xstill |
no při té rychlosti generování by se miliarda stavů generovala několik měsíců… |
| 16:51 |
xstill |
zkusím |
| 16:51 |
xstill |
a teda asi by se nevešla do paměti |
| 16:51 |
mornfall |
tak, menší framy tomu pomůžou, ale taky to není panacea |
| 16:51 |
mornfall |
splitHint zase pomůže tý paměti |
| 16:52 |
mornfall |
no a pak už asi jen profilovat profilovat profilovat |
| 17:43 |
mornfall |
xstill: hm, a simulate je rozbitej |
| 17:44 |
mornfall |
divine/algorithm/simulate.h:585:52: error: converting to 'std::tuple<divine::algorithm::Simulate<divine::instantiate::Setup_Algorithm_Simulate__Generator_Dve__Transform_None__Visitor_Partitioned__Store_DefaultStore__Topology_Mpi__Statistics_TrackStatistics_>::StopReason, long int>' from initializer list would use explicit constructor 'constexpr std::tuple<_T1, _T2>::tuple(_U1&&, _U2&&) |
| 18:00 |
mornfall |
myslím že jsem to opravil |
| 18:00 |
mornfall |
uvidíme co řekne gcc |
| 18:04 |
xstill |
skra gcc jsem netestoval |
| 18:04 |
xstill |
vždycky něco, je to boj |
| 18:05 |
xstill |
ty zbylé patche pošleš nebo čekáš až opravím PondInDivine? |
| 18:05 |
mornfall |
ještě nemám úplně jasno co s nima |
| 18:09 |
mornfall |
jinak teda když už komentuješ #endif tak by bylo dobrý tam nepsat tu podmínku v negaci :-) |
| 18:10 |
mornfall |
a to to ||defined( POSIX ) se asi může vykopnout taky |
| 18:12 |
mornfall |
navíc teda && !defined( __divine__ ) je asi taky redundantní, spíš bych fakt do 'divine compile' přidal -U__unix |
| 18:12 |
mornfall |
protože divine runtime fakt není unix :) |
| 18:13 |
mornfall |
jako je to asi víc unix než windows... |
| 18:13 |
mornfall |
ale máme fakt jen malinkej zlomek posixu |
| 18:18 |
xstill |
no, to by šlo, ale wibble se z toho celej porouchá, takže spíš až to portujeme celý (pokud to někdy nastane) |
| 18:19 |
mornfall |
co kde se porouchá? |
| 18:19 |
mornfall |
wibble se snad nemůže porouchat nějakýma ifdefama v bricks |
| 18:19 |
mornfall |
a na __unix se vůbec nekouká, takže to je snad taky jedno |
| 18:20 |
xstill |
aha, tohle bylo v brix, tak nic |
| 18:20 |
xstill |
jo wibble se vlastně porouchá když vyhodím -DPOSIX |
| 18:21 |
xstill |
tak ten patch v brix tam nedávej, je v něm ještě něco? |
| 18:21 |
xstill |
*bricks |
| 18:21 |
mornfall |
jo, #ifndef __divine__ kterej potřeba je (brick-benchmark je dost unix-centric) |
| 18:21 |
xstill |
jo divine.bc s 1 workerem -taustores už vygeneroval 830K stavů :-( |
| 18:22 |
mornfall |
to bude veselý no :) |
| 18:22 |
mornfall |
takže to bude něco mezi 30k^2 a 1M^2 :-) |
| 18:23 |
mornfall |
(úplně bez taustores je to zase zbytečně pesimistický...) |
| 18:23 |
xstill |
(ono to ještě nedoběhlo) |
| 18:24 |
mornfall |
jasně no |
| 19:19 |
xstill |
jo a teda existuje důvod proč sizeof( Pointer ) > 8 je problém, a to je raw()/fromRaw() |
| 19:25 |
xstill |
teda pokud pominu cesmi tak to používají jen porovnávací operátory, těm stačí pointr a nepotřebují tag, a streamy které by se dali napsat jinak |
| 19:39 |
mornfall |
a fromRaw se používá ještě někde jinde než v bitstreamu? |
| 19:39 |
mornfall |
hm, cesmi |
| 19:39 |
mornfall |
no |
| 19:39 |
mornfall |
to stejně zas tak nevadí ne? :-) |
| 19:40 |
mornfall |
ten bitstream vyřešit jde, to cesmi už hůř |
| 19:40 |
mornfall |
ale cesmi stejně verifikovat ještě dlouho nebudem :) |
| 19:40 |
mornfall |
co ten divine divine, doběhlo to už? |
| 19:41 |
xstill |
ne, skoro 2M stavů |
| 19:42 |
xstill |
problém je že sem to pustil u sebe, takže tomu dochází paměť |
| 19:42 |
mornfall |
no, je to radost |
| 19:42 |
mornfall |
to bude ještě boj to zverifikovat :-) |
| 19:42 |
mornfall |
ale zase, co jsme čekali, že |
| 19:44 |
xstill |
tak, pokrok je už to že to jde spustit, spíš bysme se asi měli soustředit na verifikaci menších částí, tabulky, bariéry a tak |
| 19:51 |
xstill |
hm, scheduler s nice se chová dost divně, na auře dostává můj divine s nice 11 téměř vše co chce, zatímco tvůj s 11 dostává nějakých 20 CPU z požadovaných 60 a ten můj kterej jsem přehodil na nice 19 dostává cca 9 CPU z 32 |
| 19:52 |
xstill |
mám tak trochu podezření, že to co jsem nastavil pomocí renice scheduler reálně ignoruje přesto, že to top vidí |
| 19:53 |
xstill |
čemuž by odpovídalo i to, že tvrdí, že 50% cpu není v nice (= můj divine na 32 jádrech) |
| 20:26 |
xstill |
hm, http://jlebar.com/2013/4/11/Beware_of_renice.html |
| 20:26 |
xstill |
" |
| 20:26 |
xstill |
The issue is that the setpriority syscall on Linux does not actually set a process's priority, as you might be led to believe from its man page. Instead, setpriority changes the priority of a process's main thread. It leaves the priority of the process's other threads unchanged. I haven't tested, but from reading the kernel sources, the nice syscall should behave the same way." |
| 20:27 |
xstill |
jestli renice dělá toto tak je to jasný :-D |
| 20:30 |
xstill |
teď je spíš otázka jestli si toho unix fi všimne, nebo mě budou považovat za spořádaného uživatele… |
| 21:08 |
mornfall |
:-) |
| 21:08 |
mornfall |
to je zase díra do systému |
| 21:09 |
mornfall |
ale proto taky renicujou celej strom asi :-) |
| 21:10 |
xstill |
no ona je to asi vlastnost renice celkově, nixos se chová stejně |
| 21:11 |
mornfall |
zkusil jsi to aj na process group? |
| 21:11 |
xstill |
to ne, udělal jsem potom renice -n 11 $(ls /proc/<pid>/task) |
| 21:13 |
xstill |
jo process group taky funguje |
| 21:14 |
xstill |
ale stejně je to zrada |
