Perl 6 - the future is here, just unevenly distributed

IRC log for #divine, 2017-02-26

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

All times shown according to UTC.

Time Nick Message
06:54 mornfall yaqwsx: asi máš patch kterej kterej není tam odkud pulluješ a hrabe na heap.hpp
06:54 mornfall darcs push (--dry) ti řekne
07:38 xstill jen tak pro zajímavost, když vypnut optimalizace, tak tak instance fifo-naive s 8 itermacemi běží 10 sekund v obou divinech. (a má asi polovinu stavů, s tím -O3 jak je ve skrtiptu je to zhruba 20/40). Není možný, že se to nějak blbě zainlinuje a tím tak vzniknou nějaký pontry navíc nebo něco? (Moc netuším na čem závisí rychlost srovnání, jestli jen na velikosti, nebo i na počtu
07:38 xstill pointrů…)
07:39 mornfall to že závisí na počtu pointrů je dost zjevný
07:40 mornfall a ano, je to tím že se něco 'blbě' zainlinuje, resp. ten rozdíl mezi -fno-exceptions a bez je ve frame-u těch reader/writer vláken
07:41 xstill ještě lepší je, že ta původní verze běží bez optimalizací asi 40 s (vs. 9/19 minut
07:42 xstill takže když se ti tam zduplikuje pointr, jak moc to bude pomalejší?
07:42 mornfall ...
07:43 xstill co?
07:43 mornfall co to je za otázku?
07:44 xstill jde mi o to jestli vadí multihrany v haldě
07:45 mornfall další kopie hrany je lookup do unordered_mapy navíc (a taky je to dost zřejmý z pohledu na kód nebo z krátkýho zamyšlení)
07:54 mornfall 168500 comparisons, average size 14760.8, avgcached = 54.7722, avgptrs = 78.9372
07:55 mornfall 168500 comparisons, average size 21805.1, avgcached = 130.823, avgptrs = 183.528
08:00 mornfall (rozdíl mezi avgptrs a avgcached dává taky počet objektů na tý haldě, 53 a 25)
08:06 mornfall každopádně to že to je -O3 a je to tím pomalejší nic nemění na tom, že je to legitimní benchmark
08:07 xstill počet se může lišit kvůli chybějícímu VFS v noexcept buildu (i když je skoro divný, že to tolik), nicméně je divný, že když se mainu předají dva argumenty na commandline tak se to zrychlí a to nemůže určitě zmenšit počet objektů
08:07 xstill to netvrdím, že není legitimní
08:07 mornfall není to tím, vfs dělá jen jeden objekt
08:10 mornfall nemůže, ale když to pustím except se dvěma parametrama tak 168500 comparisons, average size 15187, avgobj = 28.8296, avgcached = 59.656, avgptrs = 87.4856
08:10 mornfall takže sice nemůže, ale zmenší
08:13 mornfall jak se to stane ale nevim, protože když si tu haldu nakreslim tak nevypadá o moc jinak
08:17 mornfall když vypustim vfs tak dokonce
08:17 mornfall 168500 comparisons, average size 14847.9, avgobj = 25.645, avgcached = 54.7734, avgptrs = 79.4184
08:18 mornfall to je plusmínus stejný číslo jako v noexcept verzi
08:20 mornfall jo, kreslil jsem nějakou pošahanou verzi... je to skutečně tak že když tomu dám parametry tak ta halda vypadá jinak
08:27 mornfall nebo nevim, zas tak moc jinak na obrázku nevypadá
08:53 xstill hm, dokážeš do těch statistik dostat kolik porovnání skončilo s tím, že ty haldy nejsou stejné? Protože pokud nejsou tak se neprojde celá, a je asi možné, že přidání toho argumentu změní geometrii haldy a tím pádem se ten rozíl najde dřív
08:53 mornfall no, už vim... když se to tak vezme, tak je to úplně zřejmý
08:54 xstill (když přidám 4 a víc argumentů, tak tam problém zase je)
08:54 mornfall je to proto že to je DFS
08:54 xstill hm?
08:54 mornfall no proto se to občas zatoulá do kusu haldy kde to je stejný, podle toho jakej má tvar
08:56 mornfall stejný jsou asi jen 20 % času
08:56 mornfall (úplně stejný, kde je jedno jak rychle se ten rozdíl najde)
08:57 xstill aha
09:03 mornfall když o jedna prohloubím hash (z 5 na 6) tak ten rozdíl zmizí
09:03 mornfall (a je to celý asi o 15 % rychlejší)
09:03 mornfall (rychlejší než byl noexcept)
09:03 mornfall otázka je co to udělá se zbytkem
09:04 xstill poštvem na to pheme a za hodinu uvidíme
09:04 mornfall v heap::hash první if: if ( depth > 5 ) return content_hash;
09:06 mornfall když přepíšeš 5 na 6 mělo by se to srovnat
09:06 xstill ok
09:07 mornfall (to jsou ty magický konstanty, na jiných modelech se to tam už lámalo, tzn. nerozlišilo to žádný další stavy a počítal se ten hash déle)
09:15 xstill běží, 2514869 vs. 2743604 (případně ještě 2518269, -fno-exeptions)
09:43 mornfall jo a total v divbench report nefunguje, první řádek počítá dvakrát
09:45 mornfall bylo by vtipný kdyby si recenzent sečetl sloupec a nevyšlo mu to...
09:46 xstill to teda :-D
09:46 xstill btw. geometrie haldy se nemůže lišit mezi spuštěními stejného divine na stejném modelu, že? Jde mi o to, jestli ta halda může nějak souviset s tím šumem v datech…
09:47 mornfall určitě by se to dít nemělo
09:48 mornfall šum nezmizel ani se --single?
09:48 xstill ne
10:11 xstill hm, problém mají modely co hodně alokují pokud před nima běželo něco co taky hodně alokovalo (případně spadlo na OOM)
10:12 xstill vypadá to jako kdyby kernel nezvládal dodávat sránky přesto, že má volnou paměť
10:12 xstill 40.63%  [kernel]                  [k] ___slab_alloc
10:12 xstill 31.36%  [kernel]                  [k] update_blocked_averages
10:13 xstill divbechn v podstatě jen čeká
10:13 xstill a ten stroj má skoro 2 GB volné paměti
10:15 mornfall update_blocked_averages je scheduler
10:15 mornfall (kernel/sched/fair.c)
10:18 xstill aha možná kecám
10:23 xstill jo určitě kecám, mě zmátlo, že to pořád alokovalo a pak najednou nic a perf ukazoval, že většina věcí je v kernelu. Akorát ona většina věcí je v kernelu i pokud to zůstane někde viset a ten program nic nedělá
10:26 mornfall neškáluje to na využití CPU?
10:28 xstill no DIVINE mi zůstal viset v verify.cpp:64 (_log->meory) u posledního logu při insertu do databáze, zatím jsem ale nejzjistil, kdy se vezme koncový čas na search, takže nevím jestli je to tím, ale každopádně je to divný
10:29 xstill nebo tada alespoň to bylo na vrchu backtrace když jsem se k tomu připojil gdb po chvíli co to vypadalo že to nic nedělá
10:30 mornfall jako to že to brzdí odbc/psql je klidně možný
10:30 mornfall je to sice samostatný vlákno, ale pheme nemaj rezervu
10:30 xstill respektive on ani úplně nevysí, jen to log_pool je pomalé
10:31 xstill no ne, to je last, ten co se pouští ve wait, nevím jestli se čas měří před tím nebo potom
10:31 xstill (zatím jsem to nenašel)
10:32 mornfall čas měří log
10:32 mornfall TimedSink::progress( ... ) to utne
10:34 xstill takže log->memory by to ovlivňovat nemělo
10:36 mornfall no to který má last = true ne, ale jinak jo
10:39 xstill jo to s last je jediný, který nastavuje _time_search. Takže tohle udělá bordel v time_ce pokud to nastane
10:40 mornfall no ne, ten log->memory se volá periodicky, jen ten poslední je venku ze search_time
10:40 xstill ale volá se v samostatném vlákně kromě toho posledního, ne?
10:40 xstill tj. ty předchozí brzdí jen logování asi
10:41 mornfall no ale pheme maj jen 4 jádra
10:41 mornfall tzn. musí se to krást některému výpočetnímu
10:42 xstill to jo, ale ono je to schopný běžet třeba 10x pomaleji
10:43 mornfall zrovna jsem se díval že rozdíl mezi --aggregate min a max na 2514869 jsou bezmála 4 hodiny
10:43 xstill to je ještě výrazně horší než jsem myslel
10:46 xstill ono to vypadalo, že těch pool statistik je fakt hodně
10:47 xstill a na každou iteraci v log_pool se dělá zvlášť dotaz
10:47 xstill co když prostě ty memory statistky vykomentuju a zkusím to přeměřit?
10:48 mornfall zkus
10:49 mornfall pokud to je problém, bude ale stejnej problém se search_log (možná v menší míře)
10:54 xstill když odečtu tu duplikaci prvního řádku, tak je rozdíl v sumě 8 minut ve prosměch hashování do hloubky 6. Nicméně větščina věcí je trochu pomalejší a iv112 výrazně rychlejší. a +- šum.
11:00 xstill no rozhodně z 2764643 lezou menší čísla
11:01 mornfall jo, ten hlubší hash není dobrej fix... a bfs zatím vypadá že je ještě mnohem horší
11:04 xstill no ale, když vezmu agrregaci přes půrměr a ne přes minumul (s hashem do hloubky 5 je to naměřený víckrát) tak je ten rozdíl větší ve prospěch hashování do hloubky 6. Přeměřím pak to původní hashování bez logování té paměti pokud to bude vypadat rozumně ty logy
11:05 xstill pořád to není fix, ale je otázka jestli by to na naměření benchmarků teď nestačilo
11:06 xstill účelem toho článku nakonec není ukázat performance haldy ale výjimek
11:06 mornfall a proto se vyladí halda tak aby potřela rozdíl který by jinak -fno-exceptions vyrobilo :P
11:08 divine-next 1 new patch validated [mornfall]
11:09 xstill no, ten problém není způsobený -fno-exceptions, to že se tam neprojevil je náhoda
11:15 xstill i1, i2 jsou poolové pointry, že? tím pádem pokud jsou stejné, tak je to jistě stejné a nemusí se procházet, ne? +- asi ještě musí být stejný shadow
11:15 xstill (v compare)
11:17 xstill to by teoreticky mohlo přeskočit část stejných podstromů
11:17 mornfall nemusí, interpretace objid v nich může být různá
11:28 xstill aha
11:37 mornfall s pseudo-dfs se to trochu otočí (except je o málo rychlejší), jen je to celý 2x pomalejší
11:37 mornfall (teda iterativní procházení do hloubky)
11:39 mornfall ale počet objektů který to prošlo zhruba sedí, takže to skoro vypadá že llvm umí ten rekurzivní zápis zoptimalizovat výrazně víc
11:40 mornfall (resp. ušetří se procházení zbývajících ukazatelů danýho objektu pokud se to liší za tím prvním)
12:02 mornfall to co by pravděpodobně pomohlo je jet v tom dfs jak to bylo doteď, ale procházet posledně aktivní vlákno jako první (bylo-li stejné); problém je, jak tam tu informaci dostat
12:03 yaqwsx xstill: "ta tabulka syscallů v konstantách to cela výrazně zrychlila" - na co si mám dát pozor až do toho budu hrabat?
12:03 mornfall yaqwsx: to se dořeší pak, já jen zkonstantnil konstanty, který se pak nemusí srovnávat
12:04 yaqwsx Ah, ok.
12:29 xstill podle 2779036 (= 5) vs. 2764643 (= 6) to zatím vypadá, že hashování do hloubky 6 moc nestojí. A ta měření jsou konzistentně pod minimem z opakovaných běhů, takže to vypnutí statistik poolů zdá se pomohlo
12:55 xstill ten compare začíná od stavu, že? a předpokládám, že pointry prochází v pořadí v jakém se nachází v objetu, takže první půjde prorovnávat scheduler a tedy vlákna. Zásobníky vláken jsou také dost místo kde se dají očekávat rozdíly, takže to je OK. Nicméně jejich vzájemné uspořádání je v podstatě náhodné a stejně není jasné od kterého začít. Zároveň mezi během
12:55 xstill fifo-naive bez parametrů a s parametry se liší pořadí vláken (writer, main, reader vs reader, main, writer) noexcept má reader, main, writer stejně jako rychlejší běh nextu. Není teda možné, že je to způsobené jen permutací vláken?
13:00 mornfall jo, permutace vláken je právě nejpravděpodobnější důvod
13:01 mornfall ale když se dívám na compare teď, tak bys možná mohl naschedulovat ještě instanci s hloubkou 7 a potažmo 8, ať už teda aspoň nastavíme nějaké lokální optimum
13:02 mornfall (na libcxx a svc-pthread je taky 6 rychlejší než 5)
13:02 xstill pak je to ale dost marný s tím pořadím, ne? Leda by se nějak hintovalo při vkládání snapshotu které vlákno naposledy táhlo, tak si nedokážu představit, že se to dá prohledat nějak inteligentněji.
13:02 xstill ok, nacheduluju
13:04 xstill akorát na to už si udělám zvlášť buildy ať v tom není až takovej bordel
13:04 mornfall no marný to je, původně jsem čekal že půjde ten compare triviálně zlepšit a ono to moc nejde
13:07 mornfall chvíli jsem uvažoval že by dios mohl vlákno který jde spustit naswapovat do speciálního slotu
13:08 mornfall ale nevim jak moc velkej bordel to nadělá v symetrii
13:08 mornfall asi spíš velkej
13:11 xstill to by se pak nemohl seběhnout diamond jinak než během stejného vlákna, což ale skoro určitě znamená, že se měl seběhnout o krok dřív
13:14 mornfall jo, ten slot by asi musel být docela magickej aby to se to seběhlo, myslel jsem spíš tu zbývající množinu, která se tím asi dost možná taky může rozbít
13:15 mornfall (kdyby to byl speciální typ ukazatele, což by taky šlo, tak by se prvně musel najít, a to taky není zadarmo)
13:16 mornfall no
13:16 mornfall ale kdyby první slot scheduleru byl weak pointer kam by se to jen nakopírovalo
13:20 xstill to by muselo být něco jako specielní pointer kterej se prochází jen pokud jsou objid stejný a jinak se ignoruje
13:26 mornfall potřebujeme někdy marked pointery s nenulovým offsetem?
13:28 xstill nevím jak Heňo vyřešil pole, ale počítám, že spíš ne, proč?
13:29 mornfall pokud by marked pointer měl automaticky offset nula, tak tam je spousta bitů dál je rozlišovat
13:37 mornfall no nebo jde to udělat aj víc systematicky
13:52 xstill jak?
13:54 xstill jinak teda  --instance 2779036 --instance 2764643 --instance 2792435 --instance 2792485 je porovnání na hashování hloubky 5-8 (komplet naměřený je 5 a 6)
13:55 xstill vyjma alg a pv264 kde je ztráta do 10s se všude vyplatilo haskovat do hloubky 6 jestli se dobře dívám
15:09 mornfall teď total vypadá spíš nejlepší u 8
15:10 mornfall když se přesune typ do objid (to byl stejně asi plán) tak kus offsetu se může vyhradit na nějaký 'minor' (subtyp)
15:11 mornfall a ten marked pointer pro první thread se nemusí procházet, ale když ho compare potká může projít celej objekt a pokud potká stejnej ne-marked pointer tak to prohledá prvně tím směrem
15:12 mornfall ale na to asi stejně nebude čas, a nevím jak moc se mi zamlouvaj podobný hacky
15:13 mornfall ještě je možnost to procházení randomizovat, takže se nebude systematicky dělat chyba, ale zase to občas bude stát něco navíc
15:13 mornfall (třeba že se každej ukazatel s 50% šancí odloží na později)
15:14 mornfall dneska na to už ale nebudu mít čas, nejspíš nezbude než se smířit s tím že ty data jsou trochu fine-tuned
16:10 xstill hm, postgres na anně zabírá 14 GB z 15 GB, čas zvětšit partition

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