github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
jnthn Sounds like it 00:17
01:29 MasterDuke left 01:34 leont left 06:55 squashable6 left 06:58 squashable6 joined
nwc10 good *, #moarvm 06:58
Five minutes ago I was thinking about beer. Now I'm thinking about coffee. That's probably a better choice at this time of day 07:05
(not sure why I'm thinking about beer. This doesn't usually happen in the morning. And I didn't drink any yesterday) 07:06
nine The latter may be the explanation ;) 07:40
08:06 MasterDuke joined
MasterDuke if i dreamt about spesh candidate removal i don't remember it, so no nocturnal inspiration to work with this morning 08:19
08:39 Geth joined 08:47 domidumont joined 09:08 leont joined 09:19 sena_kun left 09:26 patrickb joined 09:33 zakharyas joined 09:35 sena_kun joined
MasterDuke just confirmed that the two specializations of reify-at-least (one before there was an eventual spesh candidate removed, one after) are identical. same callsite, same positional flags, same type tuple, same code in the befores and afters 09:46
10:26 patrickb26 joined 10:27 patrickb left
MasterDuke the impression i'm getting is that simply removing the candidate isn't enough if it's getting recreated exactly as it was before 10:35
jnthn If it's getting recreated exactly as before then apparently the data that was used for its creation is apparently now pretty similar. 10:42
I wonder if there's any left-behind statistics somewhere
MasterDuke yeah, either there's some weird cycle of initial condition, new condition causing deopts and removal, similar-to-initial condition, another new condition causing deopts 10:43
should removing the candidate clear some statistics somewhere? 10:44
jnthn /* Specialization statistics assembled by the specialization worker thread 10:45
* from logs. */
MVMSpeshStats *spesh_stats;
It's those
And no, they're held at the frame level, not the candidate level
Since they're used to decide what candidates to produce 10:46
MasterDuke oh ha, a candidate for reify-at-least is removed twice 10:51
so actually a candidate is created three times 10:52
11:18 Geth left 11:57 zakharyas left 12:21 sena_kun left 12:40 sena_kun joined 12:55 sena_kun left 12:56 sena_kun joined 13:09 zakharyas joined 13:56 Altai-man_ joined 13:58 sena_kun left 14:06 sena_kun joined 14:08 Altai-man_ left
MasterDuke ugh, i just keep looking at the same code over and over. think it might be time to switch to some other project 14:11
jnthn Was there any effect from clearning out the spesh stats hanging of the static frame spesh at the point of doing the deopt? 14:14
MasterDuke oh, i thought you meant they shouldn't be cleared since it was the frame that owned them. heh, i'll give that a try 14:15
jnthn Ah, sorry. I was only trying to point out where they are, not to imply they aren't worth clearning. :)
MasterDuke hm, adding `MVM_spesh_stats_destroy(tc, spesh->body.spesh_stats);` at the end of MVM_spesh_candidate_discard_one causes an instant segfault in MVM_spesh_stats_gc_mark 14:20
jnthn You may need to NULL it out also
yay, Ryzen arrives tomorrow evening, it seems 14:21
MasterDuke nice. you're getting a pretty beefy one, right? 14:22
no segv, but still 688k deopts... 14:23
jnthn Yes, Ryzen 9 5950X 14:27
MasterDuke i think it's getting cleared. spesh log shows an opt removal because of 949 deopts, but then the next stats shows only 389 hits
jnthn OK, that's probably a sensible thing to have done
(Clearing the stats, that is. Not rebuilding the very same deopting code over again.) 14:28
MasterDuke nice. no way i can justify upgrading from zen 2 to zen 3, but maybe when the 4s come out... 14:37
oh, but now there are some minor differences between the first speshialization made and the third 14:48
jnthn Hm, and are they in the right place? :) 14:51
MasterDuke i don't think so 14:53
after an sp_resolvecode, first had sp_guardsf then sp_guardconc. third has just the sp_guardsf. this happened twice 15:03
in "Facts, first had a `r10(45): usages=0, flags=8     Concr`, `r24(14): usages=0, flags=0`, and `r24(14): usages=0, flags=0` that the third didn't 15:04
fwiw, the deopts are all from an sp_guardtype 15:07
jnthn What do the stats that the sp_guardtype is based on look like? 15:08
(Should be able to correlate it by bytecode index)
MasterDuke you mean something like `[Annotation: INS Deopt One (idx 16 -> pc 512; line 54)]` should have numbers that match up with `Will deopt 120 -> 132`? 15:12
jnthn does it have a Logged annotation on there? 15:13
Ah, well, yes
MasterDuke oh yes
jnthn I guess it's two steps, first find the correct sp_guardtype, then Logged should have a bytecode index
MasterDuke `[Annotation: Logged (bytecode offset 506)]`
jnthn Though it may be the same as the pc (512 in your case) 15:14
OK, that 506 should appear in the stats
Assuming we're looking at the correct sp_guardtype, it can tell us why it's deciding the guard is wrth it
*worth
MasterDuke 506: 260 x type Any (TypeObj) 15:15
or 126: 4 x type Iterator (TypeObj) 15:16
not sure exactly which sp_guardtype it was 15:17
oh, but now there's a segv building nqp 15:20
`MVM_spesh_args (tc=0x5555555aa8e0, g=0x7ffff0063dc0, cs=0x100000027, type_tuple=0x7ffff0015430) at src/spesh/args.c:316` that's not a valid `cs` 15:24
15:24 patrickb joined 15:26 patrickb26 left
MasterDuke seems to be the stats destroying+NULLing. doesn't happen every time 15:28
jnthn Oh hmm 15:31
I wonder if it can happen if we are destroying a candidate and creating one in the same pass 15:32
Maybe we should only discard them after we've done this set of work
MasterDuke so far MVM_spesh_candidate_add has always been somewhere in the backtrace
jnthn e.g. last step in the worker
After producing all specializations
MasterDuke here? github.com/MoarVM/MoarVM/pull/1426...ae6695L156 15:35
oh, there is a `MVM_spesh_stats_cleanup(tc, previous_static_frames);` just a couple lines below there 15:38
which does do an MVM_spesh_stats_destroy if `tc->instance->spesh_stats_version - ss->last_update > MVM_SPESH_STATS_MAX_AGE` 15:42
jnthn Yeah, that means throw the stats away if we got no new ones for a while
It'd be nice if we could throw them away if we also deopt'd a candidate for that static frame 15:43
MasterDuke set some sort of flag on the frame when discarding the candidate and add a check for that to the if? 15:46
jnthn Yes, probably clearing it after since we only care about it in the current specialization run 15:53
MasterDuke hm, that'd actually be tricky for MVM_spesh_stats_cleanup, since it takes the previously updated frames, not the ones that were just updated (currently updated become previously updated after MVM_spesh_stats_cleanup is called) 16:01
jnthn ah 16:03
Maybe it needs doing separately then (go through the candidates we updated this time)
MasterDuke k 16:04
jnthn oh, or the plan, maybe 16:14
MasterDuke ? 16:15
jnthn The plan entries have the candidate to remove and the sf to remove it from, thus we can also find in the plan the sfs we should delete stats for too 16:17
MasterDuke right 16:18
we have `previous_static_frames` and `updated_static_frames`, could add a `static_frames_to_remove_stats_from` and push onto it in the MVM_spesh_candidate_discard_one branch, then at the end just loop through it 16:21
jnthn That would also work too 16:22
And avoid having to figure it out again later
MasterDuke oh, or just loop through the plan a second time before it's destroyed calling MVM_spesh_plan_destroy if `kind == MVM_SPESH_PLANNED_REMOVE_OPT` 16:23
s/plan/stats/ 16:24
whoops. `malloc(): invalid next->prev_inuse (unsorted) 16:27
Aborted (core dumped)`
jnthn Yes, that's what I was suggesting with the plan
MasterDuke github.com/MoarVM/MoarVM/pull/1426...60ddcccf5b seems to work 16:43
still all the deopts, but no segvs, etc 16:44
afk for a bit
18:21 domidumont left 19:14 zakharyas left 19:25 patrickb left
nwc10 I have beer. This feels like a more appropriate time of the morning for beer 19:45
jnthn Oh, beer. That's a good idea. 20:21
20:50 MasterDuke left 21:05 zakharyas joined 21:27 zakharyas left 21:55 MasterDuke joined
MasterDuke i had a very interesting golden, milk, double chocolate, stout earlier today. very good, pretty strong too, 8% abv 21:57
22:15 cog__ joined 22:18 cog_ left 23:26 squashable6 left 23:28 squashable6 joined

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!