Perl 6 - the future is here, just unevenly distributed

IRC log for #divine, 2015-11-28

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

All times shown according to UTC.

Time Nick Message
05:58 mornfall joined #divine
16:31 xstill spito: tak, začínám ti verifikovat tabulku s memory modelama :-D
16:31 xstill konečně je umíme dost na to aby to dávalo smysl
16:33 spito xstill: super, přeji ti nalézt nějakou krásnou chybu :P
16:34 xstill to dofám že ne, to už bychom fakt měli ten případ, že DIVINE našel chybu v datové struktuře kterou používal zatímco tu chybu našel :-D
16:39 mornfall no to jde furt nějak řešit
16:40 mornfall ale ... :-)
16:40 xstill tak, pokud tam tu chybu najdeme tak tohle vlastně nevadí, ono to nakonec víc vadí pokud ji nenajdeme
16:41 mornfall to taky
16:45 xstill ještě je sranda pozorovat v topu Martina jak pouští LTSmin na auře, vypadá to zhruba tak, že to několik desítek minut (!) kompiluje dve, a pak to chviličku běží načež to sežere všechnu paměť
16:46 mornfall zajímavý
16:48 xstill byl ten starý kompilátor dve tak pomalý, nebo udělali soudruzi někde chybu?
16:49 mornfall jestli neudělal nějakou haluz Martin, třeba že překládá celej beem pokaždý
16:49 mornfall ten překladač pomalej nebyl nikdy
16:50 xstill nene, visí mu to třeba 20 minut v jednom divine compile --ltsmin a vytěžuje to 1 jádro na 100%
16:53 mornfall to je nějakej těžkej bug asi
17:14 xstill musím v lednu zkusit to metacentrum, aura je malá :-D. I když my na to teda máme hrozně blbej load
18:42 xstill hm, začínám mít pocit, že implementovat slabší typy atomiků pomocí store bufferu nejde :-/ hlavně že jsem tím strávil odpoledne… už když si vezmu hloupý fetch_add s relaxed tak by mělo jestli to dobře chápu být bezpečné takhle zvýšit čítač paralelně ze dvou vláken, a to bych řekl, že store bufferem neudělám aniž bych ho vylil před tou atomickou operací…
18:42 xstill dofám, že chápu dobře tu sémantiku relaxed
19:01 xstill vida, x86 zdá se taky neumí žádnej slabší atomickej add
19:06 mornfall jenže my máme opačnej problém než x86
19:07 mornfall oni potřebujou aspoň X-silný, my potřebujem aspoň X-slabý (cokoliv, v podstatě)
19:08 xstill jo já vím
19:09 mornfall není mi teda úplně jasný proč bys nemohl tu hodnotu updatovat v tom store bufferu
19:10 mornfall možná teda bude bolet že asi musíš projet všechny
19:11 mornfall no, co se vlastně má stát když existují konfliktní hodnoty v různých bufferech
19:12 mornfall ale když je updatuješ všechny tak asi nic nepokazíš
19:13 mornfall no i když :D
19:13 xstill nevím chvíli jsem uvažoval že by to chtělo něco jako mít mít v tom store bufferu tu operaci, ale to taky nejde protože ona vrací (a ta návratová hodnota musí být taky konzistentní)
19:13 xstill zkusím se nad tím pořádně zamyslet
19:14 mornfall relaxed by mělo znamenat že se to provede jako jedna operace ale nic jinýho
19:15 mornfall (tzn. nikdo neuvidí mezistav, ale odkud se to odlepí záleží asi od toho co ten thread zrovna přečetl)
19:16 mornfall ono to trochu zní že je to v konfliktu
19:16 mornfall už v principu, store buffer sem nebo tam
19:17 mornfall na třech vláknech zejména, když maj 2 mezi sebou race na update a třetí do toho udělá atomic ++
19:17 xstill co je v konfiktu?
19:17 mornfall no že tam není žádná synchronizace a že to je zároveň atomický
19:17 xstill z cppreference: "Typical use for relaxed memory ordering is updating counters, such as the reference counters of std::shared_ptr, since this only requires atomicity, but not ordering or synchronization. "
19:18 xstill jo to jo
19:18 mornfall no to ti ale bude fungovat jen když všichni jedou na atomic
19:19 xstill jasný, mě příjde smyslupnější to co píšou v langrefu LLVM, tam píšou (u monotoic na kterej se ten relaxed překládá) že existuje pro každou memory lokaci úplné uspořádání všech monotonic operací nad ní
19:19 mornfall load-store v jiným vlákně ti to přepsat může, a stejně tak můžeš přepsat ten cizí store ty
19:20 mornfall jediný co není jasný jak přesně vybrat ty store buffery kde se to přepíše
19:20 xstill jo, jenže pokud uděláš increment a výsledek dáš do store bufferu, a tohle uděláš ze 2 vláken, tak ten výsledek nemusí být konzistentní
19:21 mornfall no ne, pokud to v žádným store bufferu není tak to rovnou zapíšeš, pokud je tak přepíšeš ten store buffer a nic neflushuješ, IMHO
19:21 xstill já bych skoro řekl, že "stačí" načíst nejnovější hodnotu ze všech store bufferů, jenže tam je problém že to se bude dost blbě určovat která je ta nejnovější když jich tam bude víc na různých vláknech
19:21 mornfall no to je asi silnější než relaxed
19:22 mornfall a nejnovější je úplná antiteze store bufferu :D
19:22 mornfall když je to ve více store bufferech znamená to že tam není happens-before
19:23 mornfall no možnost by mohla být prostě počkat než se to z těch store bufferů vylije
19:24 mornfall s tím že v nějakým proložení se to stane hned
19:24 mornfall teda asi nejbezpečnější je nondet vybrat nějakej a přepsat to tam, ale to asi bude generovat redundantní běhy
19:26 xstill no ne, ještě nejsem teda přesvědčenej, že to přepisování dává smysl, ale když to aktualizoješ jen někde budeš mít pořád ten problém, že to nebude ani relaxed, a krom toho se to nedá přepsat (ani přečíst) protože nevím jestli to na co bych koukal náhodou nebylo od ne-atomiku
19:27 xstill což vlastně dává odpověď na celé to přepisování
19:28 mornfall no to je nutně od neatomiku
19:29 mornfall proč to nebude ani relaxed?
19:29 mornfall když jsou v bufferech jen non-atomic věci, vždycky může vyhrát libovolná z nich a ten atomic ++ může vlítnout kamkoliv mezi to
19:29 xstill co? to nedává smysl, pokud bych ve store bufferu nikdy nemohl mít záznam od relaxed operace tak by musela jít mimo něj a tím pádem být SC
19:30 xstill to patří před tu tvou otázku
19:30 xstill no ne, mě teď jde o soubru dvou relaxed ++
19:30 xstill *souhru
19:31 xstill ony se a) musí dát přehodit proti libovolným loadům na jinou adresu, b) musí být vzájemně konzistentí
19:31 mornfall jo bude to potřeba oflagovat, já furt uvažuju jen jednu lokaci
19:32 xstill dvě ++ na stejnou memory lokaci
19:32 mornfall no minimálně ta druhá musí zcela nutně editovat ten buffer, před tím neutečem
19:33 mornfall takže buffer si musí někde urvat bit aby si pamatoval v jakým režimu ta buňka funguje
19:35 xstill zrovna tam bity nejsou problém, kvůli zarovnání jich tam beztak je 32 volných v každý položce protože to není packed
19:38 xstill takže ty říkáš, že atomická operace by měla se provést, zapsat výsledek do store bufferu a aktualizovat všechny atomic položky všech bufferů, které jdou na tu hodnotu na totéž co vzešlo tady?
19:38 mornfall no, ne tak docela
19:39 mornfall atomic může vyrobit položku pokud neexistuje, ale určitě by je neměl množit
19:39 mornfall a skoro si myslim, že ideální bude aby když jich existuje víc (neatomic), tak jednu vybere z tý udělá atomic a ostatní zahodí
19:40 mornfall resp. nemůže je úplně zahodit :\
19:40 mornfall flusher by je měl zahodit místo zapsání
19:41 mornfall ale když existuje atomic záznam pro nějakou lokaci měl by být nejvýše jeden a měl by se vždy updatovat jen ten (jinými atomicy)
19:41 xstill asi to nechápu vůbec
19:41 xstill jak vytvářet položky?
19:41 mornfall ve store bufferu
19:42 xstill no, to ještě chápu kde
19:42 xstill ale ne proč
19:43 mornfall hm, to beztak nefunguje
19:43 mornfall on musí ten buffer item ukrást ne přepsat
19:43 xstill a jakmile budeš něco aktualizovat tak hrozí že to nebude TSO
19:43 xstill ukrást?
19:44 mornfall tzn. funguje jako nonatomic store, ale ta load část přečte atomic-store-buffer-item pokud existuje a zruší mu ten atomic flag
19:45 mornfall s tím že ten store vyrobí pro svoje vlákno záznam s atomic flagem
19:45 xstill load ze všech store bufferů jo?
19:45 mornfall takže atomic instrukce si budou prostě podávat peška čím se serializujou
19:45 mornfall no z toho jednoho kterej má peška
19:45 mornfall pro danou memory lokaci
19:46 xstill aha takže v podstatě to co jsem říkal s tím čtením nejnovější hodnoty ze všech store bufferů, ten pešek totiž přesně označuje tu nejnovější atomickou hodnotu
19:47 xstill to by mohlo fungovat
19:47 mornfall no nejnovější atomické
19:47 mornfall nikoliv nejnovější libovolné
19:48 xstill jo
19:49 xstill vlastně to přímo odpovídá definici v langrefu :-)
21:33 xstill tak tabulka s dvěma vlákny kde každé vkládá jeden prvek a TSO bufferem hloubky 1 už zvládla vygenerovat 180 M stavů (je tam teda blbě relaxed atomic, ale to by mohlo být skoro jedno)
21:33 xstill a to to bez TSO mělo něco jako 9k stavů

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