github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
MasterDuke argh! no wonder heaptrack was (correctly) reporting such a difference in temporary allocations between my remove branch and master. i forgot FSA_DEBUG was set on my branch, which unconditionally turns every MVM_fixed_size_alloc into an MVM_malloc 09:58
oh, and now valgrind is throwing a fit about that MVM_fixed_size_safepoint i added right before the MVM_fixed_size_destroy in MVM_vm_destroy_instance 10:04
right, just need to move it before the MVM_tc_destroy and everything seems to be fine again 10:09
ah ha. and now my branch is *not* a bunch slower than master! damn you past self for turning on FSA_DEBUG 10:16
jnthn oops 10:22
MasterDuke it now seems a little bit slower in some cases and a little bit faster in others. anybody have a suggestion for a really good test case? that decont stats problem and the fix (which is included on my branch) throws off my previous example 10:31
jnthn MasterDuke: my $v = -1; sub bar() { $v }; sub foo() { my $i = 0; for ^1_000_000 { $i += $v.abs } }; foo(); $v = -1.5; foo() 10:41
That deopts a million times on faster
*master
MasterDuke huh. much faster on master (1.9s vs 2.9s), same number of deopts on both 10:45
and there are no removals in a spesh log. maybe it happened too fast? but i was running with MVM_SPESH_BLOCKING=1 10:51
jnthn Hm, I'd expect enough time for removal 10:56
I think that's about as synthetic a case as we're going to get, though, so it's worth looking into why it's not doing a good job of that 10:57
MasterDuke i see the spesh_cand->body.deopt_count increasing. 0, 78, 190, ..., 992776
and the threshold is currently only 100 to trigger a remove plan... 10:58
yeah, the `if (cand->body.deopt_count > 100) {` is never true in plan.c... 11:00
so it's incremented in stats.c, but none of the candidates in the frame in plan.c have a count > 100 11:03
nine jnthn: seems like tellable6 was awol: colabti.org/irclogger/irclogger_lo...-02-28#l10 11:08
MasterDuke hm, guess i should revert that decont stats change on my branch for more of an apples-to-apples comparison. or should i add it to master when testing there, assuming some version of github.com/MoarVM/MoarVM/pull/1438 will get merged once nine++ figures out the mis-spesh problem? 11:31
ohhh, cherry-picking that change to master slows it down to about the same as my branch. but still need to figure out why my branch isn't removing the opt and replacing it 11:38
MasterDuke huh. if i stick `if (e->deopt.spesh_cand->body.deopt_count > 100  && e->deopt.spesh_cand->body.deopt_count < 500) fprintf(stderr, "stats: frame == %p, cand == %p\n", e->entry.sf, e->deopt.spesh_cand);` in stat.c at `case MVM_SPESH_LOG_DEOPT`, and also print the sf and cands in plan_for_deopt, the frame from stats never shows up in plan_for_deopt 12:55
hm, not in this example, but when building nqp there are cases where github.com/MoarVM/MoarVM/pull/1426...7556e0R153 is false because there is no spesh log 13:21
why would that be? MVM_spesh_log_entry is the only other MVM_spesh_log_* function that checks that
and why wouldn't/couldn't we have  `MVMSpeshLog *sl = tc->spesh_log ? tc->spesh_log : MVM_spesh_log_create(tc, tc->thread_obj);`? 13:29
i guess it could race with whatever else creates it? 13:30
MasterDuke so the frame with the problem candidate does go through plan_for_deopt once, but at that point the deopt_count is only 78 13:38
and sometime after that it quickly goes to 992776. plans are run while the deopt_count for that candidate is incremented, but never again for the frame holding it 13:40
that frame is only added to sf_updated once 13:43
so somehow there isn't another `case MVM_SPESH_LOG_ENTRY`?  that's the only place where it's added to sf_updated 13:45
MasterDuke ok, so added github.com/MoarVM/MoarVM/blob/mast...#L559-L568 to the MVM_SPESH_LOG_DEOPT case and now it's faster than before (2.2s vs 2.9s) and only ~200 deopts 13:54
however it is still slower than master without the decont stat logging change
MasterDuke if i revert that change on my branch it speeds up to 1.9s (same as current, stock master) and gets rid of the deopts 13:57
surprising thing i've learned through all this...deopts aren't all that expensive. or, the cost of fixing them works out to roughly the same as the cost of running them 13:58
MasterDuke to sum up the changes (with some rough numbers): 14:28
master                                                     : 1.9s, 1m deopts
master w/ decont logging change: 3.0s, 1m deopts
branch                                                     : 1.9s, 100 deopts
branch w/ decont logging change: 2.2s, 100 deopts
nine 2.2 sounds better than 3? 14:32
MasterDuke yep 14:35
github.com/MoarVM/MoarVM/pull/1426 now updated 14:41
MasterDuke jnthn: colabti.org/irclogger/irclogger_lo...03-01#l105 17:01
lizmat and yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2021/03/01/2021-...t-of-raku/ 18:12