|
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
|
|||