|
Welcome to the main channel on the development of MoarVM, a virtual machine for NQP and Rakudo (moarvm.org). This channel is being logged for historical purposes. Set by lizmat on 24 May 2021. |
|||
| timo | (this module is only used by tools that want to properly parse the instructions in a spesh dump, which so far i think is only moarvm's tools/graph_spesh.raku) | 00:02 | |
| Geth | MoarVM/main: 17c62f129b | (Timo Paulssen)++ | tools/graph_spesh.raku freshen up graph_spesh.raku - deprecated "path" method -> IO - support lines with comments, show them in output - support uint literals - support coderefs to closures - support more than one unparsed line - mark each FH's Goto block in overview |
00:07 | |
| timo | and obviously i've been the only one who used this tool :P | ||
| MasterDuke | nice. i always forget about the various scripts/tools in the repos | 00:32 | |
| timo | spesh_goggles (my new project) is going to om nom the majority of graph_spesh.raku | ||
| MasterDuke | cool beans | 00:34 | |
| timo | /* Make a post-inline pass through the graph doing things that are better | 00:47 | |
| * done after inlinings have taken place. Note that these things must not | |||
| * add new fact dependencies. | |||
| .... uh oh? i don't think i've paid attention to this last note? and i'm not sure i understand why it exists? | |||
| 2bab220aff0be5f979218d761b3a9ed9507a445e put this in | 00:52 | ||
| MasterDuke | what does it mean to add (or not) a new fact dependency? | 00:55 | |
| timo | be56234ee03f150cf750d88ee98ca0b8b9e8328b might actually have removed the need for the comment in question | 00:56 | |
| when we set a fact in an optimization that requires another fact, the one fact can set the other fact as a dependency | |||
| some facts are set by guards created from things we logged during regular execution | 00:57 | ||
| if the facts that these guards are giving us are not used for any optimizations, they stay "unused", and then we can throw out the guard instructions | |||
| bedtime o/ | 01:01 | ||
| MasterDuke | later... | 01:03 | |
|
02:10
kjp left
02:11
kjp joined
02:12
kjp left,
kjp joined
|
|||
| MasterDuke | when building CORE.c, 9959354 VMArray's are garbage collected with 0 elems | 02:22 | |
| that seems inefficient, why did we create all those? | 02:23 | ||
| here's an example github.com/MoarVM/MoarVM/blob/main...#L878-L891 | 03:23 | ||
| 378962 times total_fates was 0 | |||
| but just returning NULL in that case breaks things | 03:24 | ||
| same with VMNull | |||
| should there be a `tc->instance->array_consts.(int|str|hll)_empty` like there is for strings? | 03:28 | ||
|
06:09
sugarbeet left,
sugarbeet joined
|
|||
| nine | Arrays are mutable | 06:53 | |
| Geth | MoarVM/main: 5e52422f43 | (Stefan Seifert)++ | src/io/procops.c Add missing MVMROOT to spawn_setup MVM_repr_box_int can allocate which can trigger the GC. This would move the freshly allocated arr which outdates our pointer. |
07:04 | |
|
07:46
harrow left
07:49
harrow joined
07:57
evalable6__ joined
|
|||
| timo | we do have a potential mechanism that we can use to cause a violent explosion if any code ever tries to add anything to the "empty array" constant. but do we actually allocate the storage for the VMArray in question? | 08:01 | |
|
08:02
evalable6 left
|
|||
| timo | but making the code cope properly with a VMNull returned from nfa_run would also be a good idea so we can leave these allocations out entirely | 08:02 | |
| it requires a rebootstrap :D | 08:17 | ||
|
08:22
lizmat left,
gfldex left,
ingy left,
coleman left,
JRaspass left
08:34
lizmat joined,
gfldex joined,
ingy joined,
coleman joined,
JRaspass joined
14:14
MasterDuke left
17:42
sena_kun joined
20:55
sena_kun left
|
|||
| timo | m: say 7566820 * 100 / (7566820 + 9483189) | 21:03 | |
| camelia | 44.380152527 | ||
| timo | m: say 7557710 * 100 / (7557710 + 9863325) | ||
| camelia | 43.38266928 | ||
| timo | i put a fprintf with 0 or 1 if the elems of a VMArray had 0 elems at time of gc_free, and when returning VMNull from nfa_run with an empty fates array, these are the numbers i get from core setting compilation | 21:04 | |
| the number starting in 7 is the number of non-empty arrays | 21:05 | ||
| lizmat | so most of them remain empy ? | 21:07 | |
| timo | yeah, the biggest source of arrays that end up empty is not the NFA runs | ||
| actually, this also includes arrays that have had all their elems popped or shifted out | |||
| that's not what i wanted to measure | 21:08 | ||
| m: say 9742214 * 100 / (9742214 + 7307728) | 21:17 | ||
| camelia | 57.13927942 | ||
| timo | m: say 9734298 * 100 / (9734298 + 7731185) | ||
| camelia | 55.73449071 | ||
| timo | now the number with the 9 is when an array had slots allocated, the number with the 7 is when it had no slots allocated, so it was empty at the end and never had anything in it in the first place | 21:20 | |
|
21:21
MasterDuke joined
|
|||
| timo | with rr i can take an array at the time it's freed, set a watchpoint for when it was created, and travel back in time to get a stack trace of its creation | 21:25 | |
| MasterDuke | nine, timo: yeah, i was thinking last night about how arrays are containers and that makes this analysis harder. especially since there might be a lot of `while (@a.shift) {}` or `while (@a.pop) {}` throwing my numbers off | 21:26 | |
| timo | thankfully we have not just elems but also sslots | 21:29 | |
| no ssize is the name | |||
| MasterDuke | right, i mean to rerun and print that out also... | 21:31 | |
| 7731257 gc_free of 0 elems and 0 ssize | 21:32 | ||
| so i guess those are the candidates for trying to not even MVM_repr_alloc_init() | 21:35 | ||
| btw. why do we adjust the nursery for bigints and the buffers used in async io, but not for arrays or hashes? | 21:37 | ||
| afk for a while | 21:38 | ||
| timo | i guess for hashes we usually also get pressure from MVMObjects we put in? arrays on the other hand can of course be native int arrays and such | 21:43 | |