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.
00:02 reportable6 left 00:03 reportable6 joined 06:02 reportable6 left 06:05 reportable6 joined 06:56 discord-raku-bot left 06:58 squashable6 left 07:00 squashable6 joined 07:09 discord-raku-bot joined 07:31 discord-raku-bot left 07:32 discord-raku-bot joined
MasterDuke how optimize(d|able) is MVM_serialization_read_ref? 09:13
and MVM_serialization_read_int 09:16
i modified rakudo-m.c to call the execv of moar 1000 times in a loop so perf would have more data to work with 09:17
and those are the top two functions
Nicholas I believe that folks have worked pretty hard on MVM_serialization_read_int 09:27
I don't know as much about MVM_serialization_read_ref 09:28
11:11 frost joined
nine So, it looks like when cleaning up spesh stats that didn't get updated for a while, we free the MVMSpeshStats structure and remove the reference from the MVMStaticFrameSpesh object holding it, but it may still be referenced from a MVMSpeshSimStackFrame. 11:52
12:02 reportable6 left 12:03 reportable6 joined
nine A possible fix could be to look through all tc's spesh_sim_stacks for frames still referencing the MVMSpeshStats and just not free it then. Or alternatively to trow away that whole sim stack. 12:04
The situation that we throw away an MVMSpeshStats when its still referenced from some sim stack seems to be rather common actually. What's rare is that the sim stack gets processed again. 12:18
If only I could reproduce this crash somehow. It's pretty clear from the code but the situation seems to be incredibly rare 12:35
14:20 Altai-man_ joined 14:39 frost left
MasterDuke then i guess we need to figure out a way to just do fewer MVM_serialization_read_int calls 15:34
github.com/faster-cpython/ideas/issues/32 has a bunch of idea they're trying for speeding up python startup (where i got the idea to run the exec in the runner multiple times for better perf stats), i wonder how many of them are relevant for us 15:35
16:57 Altai-man_ left 18:02 reportable6 left 18:05 reportable6 joined 18:20 Altai-man left 19:33 evalable6 left, linkable6 left 19:35 linkable6 joined 19:36 evalable6 joined
Nicholas MasterDuke: given that you're in a position to benchmark, do you see any changes (better, or, I guess worse) if you rebase the branch from github.com/MoarVM/MoarVM/pull/1448 onto master and retest? 20:09
20:22 sena_kun joined 21:39 linkable6 left, evalable6 left 21:42 evalable6 joined, linkable6 joined
MasterDuke Nicholas: something is odd. that branch is 5x slower. i dropped the number of iterations to 500, and master is ~6.85s, but your branch (after being rebased) is ~30s 22:18
for master, perf shows the top function is MVM_serialization_read_ref at ~5%, but your branch has mutex_spin_on_owner (from the kernel) as top at ~40% 22:19
(oh, looks like it's actually 100 iterations) 22:20
fwiw, gist.github.com/MasterDuke17/1cc0d...b8570661f4 is my diff 22:21
22:28 [Coke] left