Perl 6 - the future is here, just unevenly distributed

IRC log for #divine, 2015-10-22

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

All times shown according to UTC.

Time Nick Message
19:10 xstill ono to s tou komresí v partitioned nevypadá zas tak marně
19:12 xstill jakože úspora 42x na 64 vláknech/tabulkách při 64 M stavech, to není marný
19:27 mornfall a kolik je to s shared?
19:45 xstill míň, ale nemám to obenchmarkvané na tomhle divine, respektive nevím jestli je to přesně ten stejný model ale tuším něco kolem 150 - 200 b / stav oproti 700 b / stav nebo tak něco
19:59 mornfall to teda znamená že v tom lepším případě 64x více RAM umožní zhruba 18x větší stavový prostor?
20:04 xstill to ti řeknu, až to doběhne, už je to teda na 550 b / stav
20:04 mornfall to v podstatě znamená že z 64 strojů bude 46 jen dorovnávat ztráty v efektivitě komprese, to mi zas tak dobrý nepřipadá
20:05 mornfall jo to není finální číslo
20:05 xstill není
20:06 xstill navíc mám podezření, že jsem omylem pustil jinej model než jsem myslel a ty čísla pro shared tahám z paty
20:08 mornfall na druhý straně se dá očekávat, že partitioned+tree bude efektivní <=> distributed-shared bude rychlý
20:08 mornfall (protože pro distributed-shared to znamená že i s relativně malou cache bude většina věcí v tý cache)
20:09 xstill aha, chvíli mi to nedávalo smysl, ale došlo mi to :-D
20:21 xstill zas na druhou stranu, 64 není úplně malý číslo pokud by byla alespoň dvouvrstvá architektura, ale uznávám, že efektivně vyžít čtvrtinu paměti není úplně výhra
20:28 xstill ale teda pokud bychom měli efektivní distributed shared tak je otázka jestli skoušet kupovat 1 server za 2 mega, nebo raději třeba 4 po 500k, protože pak bychom dokázali mít 3TB ram + 8 * 18 jader například
20:30 xstill teda spíš 8 * 16 do těch 500k
20:36 mornfall zkoušet*
20:37 mornfall každopádně distributed-shared ti „zaručí“ efektivitu v RAMce (všechno se distribuuje až na konstantní násobek počtu výpočetních uzlů)
20:38 mornfall zatímco partitioned+tree ti „zaručí“ efektivitu v komunikaci/rychlosti
20:38 mornfall i když teda tím že v partitioned se vždycky posílá celej stav, není to možná zas tak jednoznačný
20:47 xstill co myslíš tím "až na konstantní násobek počtu uzlů?"
20:47 mornfall cache, kopie divinu, kopie modelu
20:48 mornfall prostě nějakou konstantní paměť na každým uzlu ukrojíš
20:48 mornfall a zbytek se sečte
20:48 xstill aha takhle
20:54 xstill btw. jestli si dobře pamatuju jak velkej divine byl tak za 2-3 roky nám narostl zhruba na dvojnásobek kódu (máme momentálně asi 62 kloc - teda 8 kloc LTL2BA a 2 kloc coin parser)
20:55 mornfall on se zase rychle zmenší :-)
20:55 xstill takže když to trochu zeštíhlíme bude to jen plus
20:55 xstill :-)
20:56 xstill uvidíme kolik, 10 kloc je LLVM interpreter (+ ta část userspace co je v divine/llvm), což je zhuba tolik co ostatní generátory dohromady :-D
20:57 xstill aha, tak ono 5 kloc z toho je ten userspace
20:59 mornfall z toho většina filesystem
20:59 mornfall a většina zbytku pthready
20:59 mornfall (odhaduju)
21:00 xstill fs je cca 3 kloc, pthread 1400 loc, takže jo
21:01 xstill jen tak čistě teoreticky, myslíš že by se z toho spitova fs dala udělat knihovna která by mohla jet jako LD_PRELOAD?
21:01 mornfall jo to by mělo jít, pokud není nějak vadná
21:01 mornfall (teda ta implementace)
21:04 xstill to by mohla být totiž docela sranda, a i prakticky by to mohlo být použitelné na nějaké testovací environmenty
21:04 xstill sakra, mohl bych psát česky :-/
21:20 xstill je docela trapný, že standard nedefinuje žádné utility funkce pro implementaci std::hash… alespoň něco co sežere kus paměti s délkou a udělá z toho hash by tam být mohlo…

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