Perl 6 - the future is here, just unevenly distributed

IRC log for #divine, 2014-08-08

| 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/
15:01 mornfall xstill: FakeGeneratorFixed -- co to má dělat? :-)
15:01 mornfall (musel jsem překopat splitHint protože jak to je v tom LLVM splitter napsat nejde...)
15:03 mornfall přijde mi že to dělá hřeben s n listama a n-1 forkama
15:06 xstill nevím zpaměti, podívám se
15:06 xstill jo rozseká to (= blob - extension) na kousky velikostí daných těmi parametry
15:06 xstill jo rozseká to (= blob - extension) na kousky velikostí daných těmi parametry
15:07 xstill jo jako hřeben asi
15:07 xstill ale to je dokonce asi jedno
15:07 mornfall právě mi přijde že to je docela zbytečný to hřebenovat
15:08 xstill asi mi to přišlo nejjednodušší
15:10 xstill jen teda možná nastanou konflikty v ntree, protže jsem tam nahrzoval nějaký Blob za T, ale to by nemělo být těžké vyresolvovat
15:11 xstill opravuju ten PondInDivine a při té příležitosti jsem si myslel, že jsem udělal pool který funguje všude kromě MPI a NTree
15:12 xstill ale je to blbě, protože AtomicCell taky nefunguje
15:12 xstill (udělal jsem to v Pond bez tagu)
15:14 xstill v divine to funguje ale clang jaksi odmítne CAS na 16B proměnné
15:15 xstill *divine.bc
15:19 mornfall to bys mu asi musel dát nějakej -march
15:20 mornfall 16B CAS neumí všechny x86-64 procesory
15:37 xstill ani to nefunguje, asi clang vůbec neumí větší atomic
16:09 mornfall xstill: hm, splitHint z graph.h má dělat něco jinýho než FakeGeneratorBinary nebo to stejný?
16:10 mornfall hm, asi něco jinýho
16:12 mornfall chvíli mi přišlo že to je plochý (bez forků), ale je to taky binární
16:14 mornfall já bych tam teda dal quadtree když už :-)
16:17 mornfall jako, mam docela chuť to parametrizovat
16:17 mornfall --compression={none,bintree,quadtree,adaptive}
16:17 mornfall pak by to třeba šlo i měřit...
16:33 xstill tak to by asi mělo smysl
16:34 xstill splitHint dělá v podstatě totéž co FakeGeneratorBinary ale asi o trochu líp, protože se snaží negernovat tolik různý délky listů
16:36 xstill teda myslím, že by to měl délku n rozdělit na x1 = 2^i, x2 = n - x2 tak že x1 je co nejblíž k n/2
16:37 xstill protože jinak ti hrozí, že pro proměnlivě dlouhé bloby budeš mít pokaždé úplně jiné délky částí
17:12 mornfall jo, to jsem nějak vytušil
17:15 mornfall tzn. chci dělit na s = l^(ceil(log_2(l))-1) => (s, l - s)
17:16 mornfall resp. pro n-ární strom s = l^((ceil(log_n(l))-1) => (s, s, s, l - s) ... nebo tak něco :-)
17:17 mornfall počítám že ty bitops tohle nějak zhruba dělají, jen bez fpu
18:41 xstill tak msb je prakticky nejbližší číslo tvaru 2^i vyšší než n/2
18:41 xstill tam je jen ten problém pokud n = 2^i
18:42 xstill přišlo mi zbytečný používat fpu
18:42 xstill ale je to asi jedno
18:52 mornfall no, fpu je asi nutně pomalejší
19:59 xstill zajímavý, tak jsem chtěl zjisti jestli vyskočit z callbacku nad vektorem je lepší pomocí výjimky, nebo si přehazovat návratovou hodnotu a pokaždé to testovat
20:00 xstill clang se mě teda snažil přechcat a vyoptimalizovat mi celý benchmark pryč pro if verzi, ale přesvědčil jsem ho
20:01 xstill a výsledek je že pro 1024 prvů je overhead výjimek < 10x a zhruba pro výrazně vyšší hodnoty jsou výjimky rychlejší
20:03 xstill no super, gcc nezkompiluje std::vector< volatile long >
20:07 mornfall zajímavý :-)
20:08 xstill ale vyčetl bych z toho, že vyhodit a chytit tu výjimku tvá cca 13 milisekund
20:08 mornfall to není úplně málo
20:09 mornfall (shodou okolností mám někde patch kterej implementuje isPrivate bez výjimek...)
20:10 mornfall ale přijde mi divný že by mělo mít to testování nějakej overhead
20:10 mornfall když se ten stack zinlinuje dohromady tak by to mělo být buď if ( x ) break; vs if ( x ) throw...
20:11 mornfall a ten break nemůže nic stát pokud se neděje moc často
20:11 mornfall (protože branch prediction)
20:11 xstill no nevím, ten overhead je hodně nízkej
20:12 mornfall můžeš někde pastnout ten benchmark?
20:12 xstill možná až moc na to aby se dalo mluvit o tom, že je to rychlejší (tzn tak 1-3 procenta)
20:12 xstill jo
20:13 xstill nicméně to je konzistentní mezi běhama
20:13 mornfall zkusil bych -O3
20:14 xstill http://pastebin.dqd.cz/DI8n/
20:14 xstill však s -O3
20:14 xstill bez optimalizací je ten overhead cca 40%
20:15 xstill hlavně proto, že je tam jump navíc
20:15 xstill hm, pokud by se to správně optimalizovalo tak by tam mělo být stejně jumpů, divný
20:15 mornfall co se stane když to přepíšeš na if ( !f(...) ) break?
20:15 xstill zkusím
20:16 mornfall řekl bych že ho mate ta extra proměnná
20:17 xstill to osciluje kolem 0 (+- 1%)
20:17 xstill zajímavý
20:17 xstill taková drobná změna
20:18 mornfall ještě by mohlo pomoct otočit ten test
20:18 mornfall (cont && it != ...)
20:18 xstill hej já sem kecal, ten overhead je 13 mikrosekund a ne 13 milisekund :-D
20:19 xstill teda teď to vypadá spíš jako 20, ale to jedno
20:20 mornfall to zní asi víc uvěřitelně no
20:20 xstill to je asi jedno (otočit podmínku)
21:20 mornfall hmm
21:23 mornfall xstill: má nějakej zásadní smysl aby byl v timed toplevel split dvousměrnej místo 3-směrnej?

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