|
github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm Set by AlexDaniel on 12 June 2018. |
|||
|
00:19
AlexDaniel`` joined,
ilmari[m] joined
00:27
AlexDaniel left,
AlexDaniel joined
02:49
shareable6 joined
04:10
Redfoxmoon left
04:15
Redfoxmoon joined
04:19
MasterDuke left
05:22
squashable6 joined
05:47
domidumont joined
05:52
domidumont left
05:53
domidumont joined
06:13
domidumont left
06:28
robertle joined,
brrt joined
|
|||
| brrt | good * | 06:32 | |
|
06:56
domidumont joined
|
|||
| brrt | before i could sleep yesterday i thought of a way to do a concurrent lockless hash table | 07:02 | |
|
07:05
AlexDaniel left
|
|||
| nine | brrt: let's hear it! | 07:32 | |
| nwc10 | "and when I woke up it turned out it was all a dream" | ||
|
07:38
brrt left
08:03
lizmat left
08:11
Redfoxmoon left,
Redfoxmoon joined,
lizmat joined
08:23
zakharyas joined
08:52
AlexDaniel joined
08:55
robertle left
|
|||
| samcv | nwc10: haha | 09:05 | |
| well i'm heading to bed. night all o/ | 09:06 | ||
|
09:17
AlexDaniel`` left,
AlexDaniel`` joined
|
|||
| jnthn | Lock-free hash tables are possible, though quite tricky :) | 09:20 | |
| There's a good presentation on the one in Java somewhere | |||
| Though that design turned out to have a subtle semantic bug that was discovered only relatively recently | 09:21 | ||
|
09:29
scovit left
09:32
brrt joined
09:44
robertle joined
09:51
brrt left
10:17
brrt joined
|
|||
| brrt | it is at least a minor blog posts' worth of information | 10:17 | |
|
10:19
domidumont left
|
|||
| brrt | but, the very short version is that you can do it, but you're writing soooo many atomic increments/decrements/compare-and-swaps | 10:19 | |
| that the average case performance is probably not going to be great | |||
| timotimo | so, we have a whole bunch of hashes, right, that already reached their most likely final size when we deserialize them, like method tables and such | 10:20 | |
| would it make sense to make them exactly as big as needed to contain what they have in them at that moment? | 10:21 | ||
| Geth | MoarVM: 217b6876a3 | (Jonathan Worthington)++ | 5 files Generalize attribute_as_atomic to obj attrs too In preparation for adding some atomic store and atomic bind ops for attributes. |
10:53 | |
| jnthn | timotimo: Perhaps so, yes | ||
| I guess at the moment we end up with some resizes thanks to that | |||
| timotimo | i'm not sure how you mean that? | 10:57 | |
| jnthn | We probably resize the hash table during deserialization | 10:58 | |
| Whereas with what you're suggesting we'd not need to | |||
| timotimo | i assume we just create the hash and hash_bind as often as we need to | ||
| bind_key* | |||
| jnthn | Right | ||
| timotimo | that'll double the size every time it runs out, or something | ||
| i want to write something that'll tally up memory wasted from all kinds of sources and see what a -e '' looks like when it exits | 10:59 | ||
| particularly of interest are FSA pages that are barely used and hash/array usage percentages, but surely there's more i'm not thinking of yet | 11:00 | ||
| also, ISTR having strings with the same contents copied all over the place when i last used that gdb heap scan script | 11:03 | ||
| Geth | MoarVM: e485ab3384 | (Jonathan Worthington)++ | 8 files Add atomicbindattr_o and casattr_o ops So that we are able to implement the relevant container operations in NQP code rather than having to write them in C. |
11:07 | |
| brrt | jnthn: in the 'racing to writeness wrongness leads' - if i were to call `atomic` for the block, `serial`, i'm fairly sure you'd know a way to implmeent it ;-) | 11:26 | |
| timotimo | percentage_used_buckets = {307, 34, 0 <repeats 99 times>} | 11:45 | |
| oh, forgot to multiply by 100 :) | 11:46 | ||
| lizmat | timotimo: news.perlfoundation.org/2017/09/gra...l-6-p.html # gentle reminder for a progress report | 11:47 | |
|
11:51
zakharyas left
11:56
AlexDaniel left
|
|||
| jnthn | brrt: My currnet work is shrinking the extops quite notably, which I figure will make you happy :) | 12:42 | |
|
12:44
scovit joined
|
|||
| timotimo | so in a perl6 -e '' at the end we have 752 hashes that only have two items in them, 35 with only one. after that we have 56 x 3, 20 x 4, 13 x 5, 29, 4, 7, 35, 5, 3, 4, 2, 3, 1, 4, 1, 3, 0, 1, ... | 12:47 | |
| hashes start at 8 buckets | 12:48 | ||
| a vast amount of them have either "scope" and "lazy_value_from", or "value", "scope", and "lazy_value_from" | 12:54 | ||
| jnthn | Ah, those'll be the CORE.setting symbols table I guess | 12:55 | |
| timotimo | this is for -e 'use nqp; nqp::force_gc(); nqp::exit(1)', output'd from gc_mark | ||
| hm, we have to keep that around in case we ever want to EVAL again? | 12:56 | ||
|
12:56
ChanServ sets mode: +o mst
|
|||
| jnthn | Not sure why it's kept around; they're built at setting load time, I think | 12:56 | |
| But I don't recall us caching that. So hmm. | 12:57 | ||
| timotimo | well, it's about 750 of those (assuming it only runs gc once in that program) | 12:58 | |
| the key objects appear to be re-used just fine, which isn't surprising as they surely come from the constant table | 13:00 | ||
| but every entry is 4 pointers one "unsigned" (i think that's 32bit?) and an MVMhashv which i think is 64bit now? | 13:01 | ||
|
13:03
AlexDaniel joined
|
|||
| timotimo | 40 bytes per UT_hash_handle, plus another 48 for the UT_hash_table itself? | 13:05 | |
| plus 16 * 8 == 128 bytes for the bucket array? | 13:06 | ||
| jnthn | It's also somewhat costly to build this stuff | 13:09 | |
| timotimo | does the symbol table usually have many entries in these hashes? | ||
| jnthn | I'd wondered if we could manage some kind of "synthetic" block to handle setting symbols that just does introspection | ||
| timotimo | i'm surely not seeing all of them | ||
| jnthn | It's a per-symbol hash, and what's in there varies widely | ||
| timotimo | OK. because if it's usually very small, it could become an array instead. though since we have an actual object system, we could handle either a hash or an array being there everywhere we touch it (providing API functions where sensible) | 13:10 | |
| brrt | it does! :-) | 13:32 | |
|
13:38
AlexDaniel left
13:41
AlexDaniel joined
|
|||
| timotimo | at the end of perl6 -e '', the differences between alloc_pos and alloc_limit of all FSA size pages sums up to 3_848_400 bytes | 13:42 | |
| m: say 3_848_400 / 1024; say 3_848_400 /1024/1024 | |||
| camelia | 3758.203125 3.67012 |
||
| timotimo | three and a half megabytes of memory ready to be used for allocations | ||
|
13:52
zakharyas joined
|
|||
| timotimo | m: sub avg(@a) { say @a R/ [+] @a }; avg <75572 75000 75468 75224 74832 75288 75456 75484 74964>; avg <74924 74796 74376 74624 74668 74404 74652 74784 74808> | 14:24 | |
| camelia | 75254.222222 74670.666667 |
||
| timotimo | m: sub avg(@a) { @a R/ [+] @a }; say (avg <75572 75000 75468 75224 74832 75288 75456 75484 74964>) - avg <74924 74796 74376 74624 74668 74404 74652 74784 74808> | 14:25 | |
| camelia | 583.555556 | ||
| timotimo | m: sub avg(@a) { @a R/ [+] @a }; say (avg <75572 75000 75468 75224 74832 75288 75456 75484 74964>) - avg <74852 74896 74812 75056 74468 74572 74728 75020 74644 74568> | 14:27 | |
| camelia | 492.622222 | ||
| timotimo | the first one is with 512 * page_num as upper bound, the second one with 1024 * page_num as upper bound | 14:28 | |
| not such a drastic win somehow | |||
| m: sub avg(@a) { @a R/ [+] @a }; say (avg <82164 82064 82400 82256 82188 82104 82428 82352 82380 82140>) - avg <82008 82080 81760 82108 81388 82052 81872 82096 81708 82208> | 14:40 | ||
| camelia | 319.6 | ||
| timotimo | the winnings shrink when gc is run once | ||
|
14:51
brrt left
|
|||
| [Coke] | @a.sum/@a | 15:02 | |
| timotimo | oh, that's better | 15:05 | |
|
15:18
robertle left
|
|||
| timotimo | jnthn: how do you feel about making the initial pages in each FSA size class smaller? | 15:46 | |
| jnthn | What benefit do we get? | 15:47 | |
| And will be get any for anything besides the empty program? | 15:48 | ||
| timotimo | hm, what would be a good test workload, i wonder | 15:49 | |
| jnthn | Well, something like zef probably loads a bunch of modules that it's made up of | 15:51 | |
| Which'd point out if some pages sizes are especially wasteful and thus worth it | |||
| timotimo | ok, i'll try zef list --installed as a benchmark perhaps? | 15:52 | |
| jnthn | Seems reasonable | ||
| timotimo | m: sub avg(@a) { @a R/ [+] @a }; say (avg <129936 131580 130924 130840 131412 129548 130952 129856 129376>) - avg <129760 130528 129528 129580 130644 129516 130216 130336 130532 130224> | 15:55 | |
| camelia | 405.155556 | 15:56 | |
| timotimo | m: sub avg(@a) { @a R/ [+] @a }; say (avg <129936 131580 130924 130840 131412 129548 130952 129856 129376>) / avg <129760 130528 129528 129580 130644 129516 130216 130336 130532 130224> | ||
| camelia | 1.0031145 | ||
| timotimo | so in a bigger program it's only like 0.3%? | ||
|
15:58
brrt joined
|
|||
| timotimo | m: say 75254.222222 / 74670.666667 | 16:01 | |
| camelia | 1.007815057519 | ||
| timotimo | oh, in the almost-empty program it was already only like 0.7%? | ||
|
16:23
robertle joined,
domidumont joined
16:27
huggable joined
16:28
lizmat left
16:34
AlexDaniel left
16:46
ggoebel left
17:05
ggoebel joined
17:11
lizmat joined
17:31
Zoffix joined
|
|||
| Zoffix | New blog post: "A Call to Action: Polish Perl 6 First Steps Experience": rakudo.party/post/A-Call-To-Action...Experience | 17:38 | |
|
17:57
Zoffix left
18:20
domidumont left
18:28
AlexDaniel joined
18:41
dogbert17 joined,
zakharyas left
18:58
brrt left
19:45
robertle left
21:10
MasterDuke joined
22:38
lizmat left
22:53
lizmat joined
|
|||