|
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. |
|||
| Geth | MoarVM/legojit_simple_register_tracker: 5cde10b102 | (Timo Paulssen)++ | 3 files simple manual register content tracking for the lego jit This allows us to reuse values in registers instead of recalculating them: * if a frame's register ("work") is already in TMP1 * if the effective_spesh_slots is already in a register * if the cur_frame is already in a register * if VMNull is already in a register This makes our emitted jit frames a little bit smaller, and maybe faster |
00:20 | |
| MoarVM/moar_gdb_jitreader: 872130434c | (Timo Paulssen)++ | 2 files Add a module for the gdb jit-reader functionality |
|||
| timo | decided it's past the time to share these | 00:21 | |
| unfortunately i've just gotten a segfault from the legojit_simple_register_tracer branch on my jit comparify script, of all things :D | 00:22 | ||
| ah, it's called "jit comparify" but all it has to do with jit is that its primary output was the before/after of jit bytecode sizes | |||
| oof, "rr replay" on a process that takes a few minutes and most of the time utilizes around 10 of my cores takes a little while :D | 00:28 | ||
| MasterDuke | i'm thinking about upgrading to zen5 when they're released. i've loved this zen2, but new cpus are faster... | 00:33 | |
| timo | i ran "rr pack" while a "rr replay" was running and rr is not happy about that ... | 00:38 | |
| MasterDuke | if cuthullu appears tomorrow we'll know who to blame | 00:43 | |
| timo | i've been looking for something in rr's help and website and wiki that would let me skip to a much later event instead of having to wait for it to run until then ... | 01:02 | |
| there's something in "rr replay" that's about "exporting checkpoints" which i guess means you can have one rerun that saves checkpoints at some points you want, and then another rr replay can connect to it and wouldn't have to do all the work again for these specific checkpoints? there is barely any explanation of this feature | 01:03 | ||
| i couldn't even find out when you're supposed to need "rr rerun" instead of "rr replay" or what's different about it | |||
| MasterDuke | i've never even heard of 'rr rerun' | 01:09 | |
| timo | github.com/rr-debugger/rr/pull/3406 | 01:29 | |
| rerun seems like it's mostly a thing for when rr b0rks and you need to debug rr? | |||
| MasterDuke | that'd be nice | 02:19 | |
|
07:01
sena_kun joined
19:06
rypervenche left,
rypervenche joined
|
|||
| timo | i'm now building the "persistent checkpoints" PR for myself to use | 20:17 | |
| MasterDuke | i couldn't think of a fast and easy way, so i just stuck some prints where strings are allocated and we'll see if there's a hotspot for when the size is small enough for in-situ | 21:00 | |
| huh. tons in MVM_string_concatenate | 21:05 | ||
| looks like next most common are get_all_in_buffer, do_case_change, and take_chars | 21:07 | ||
| timo | oh i think i looked into case change a few weeks/months ago when i found we do create a boatload of strings there | ||
| somewhere in the parser, i think, we have some category name or other that we always upper or lower case? | 21:08 | ||
| MasterDuke | MVM_string_concatenate creates strands, but i wonder if it'd be more efficient to create in-situs if they're small enough | ||
| timo | yeah, if they're small enough, i expect there'd be a win there | 21:12 | |
|
21:20
sena_kun left
|
|||
| timo | btw there exists something fun where you can tell the kernel "hey, mark all my memory pages as clean right now" and then later "hey which of these memory pages have been dirtied since i told you to mark them clean?" | 22:12 | |
| i don't have an idea what exactly to do with it | 22:13 | ||
| there was a bug in the persistent checkpoints branch that moar managed to tickle, and the dev who made that feature was around to fix it \o/ | 23:05 | ||