github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
02:42 MasterDuke left 04:12 coverable6 left, bisectable6 left, quotable6 left, benchable6 left, releasable6 left, nativecallable6 left, tellable6 left, evalable6 left, unicodable6 left, committable6 left, bloatable6 left, sourceable6 left, greppable6 left, linkable6 left, statisfiable6 left, shareable6 left, notable6 left, squashable6 left, releasable6 joined, committable6 joined 04:13 bloatable6 joined, squashable6 joined, tellable6 joined, unicodable6 joined, evalable6 joined, nativecallable6 joined, sourceable6 joined, benchable6 joined, quotable6 joined 04:14 bisectable6 joined, notable6 joined, greppable6 joined, linkable6 joined 04:15 statisfiable6 joined, coverable6 joined, shareable6 joined
nwc10 m: say "good *, #moarvm" 06:40
camelia good *, #moarvm
08:37 zakharyas joined 09:17 MasterDuke joined 09:18 dogbert11 left, dogbert11 joined 09:19 rba left, rba joined
MasterDuke jnthn: re colabti.org/irclogger/irclogger_lo...02-10#l120 i just realized i'm not sure exactly what the "first" thing is that's necessary for correctness. converting the slot from an index to holding the MVMSpeshCandidate (done)? or not using the candidate (in the invoke_* ops?) if it has the invalidated flag set? 09:22
nine MasterDuke: it's about the caller. You realize that your spesh_cand deopts too often, so you want to get rid of it. But there are probably lots of other spesh cands that call into yours. As long as they reference your spesh_cand (in their invoke ops) your spesh_cand won't go away. So the removal needs to become recursive 09:47
Somehow this reminds me of a quote from Stargate (the 1994 movie): "I will kill you and everyone who has seen you" 09:51
09:53 domidumont joined
nine Ah, it's actually "Then I will destroy you and all who have seen you" which is even more apt ;) 09:55
10:05 domidumont left
MasterDuke nine: hm, but i don't think an 10:15
MVMSpeshCandidate knows about things calling it, or what it calls, right? 10:16
nine probably not
yet... 10:17
MasterDuke the yak's hair is growing!
nine Shave, shave, shave the yak. Shave it till it's clean... 10:18
10:19 brrt joined
MasterDuke heh, i added `else if (spesh_cand->body.discarded) printf(stderr, "Oops, this frame was passed a discarded spesh cand!\n");` here github.com/MoarVM/MoarVM/pull/1426...c7a0abR519 10:25
prints 688k times when i run that example 10:26
nine there you have it :)
MasterDuke however, a similar if here github.com/MoarVM/MoarVM/pull/1426...ca0edR2077 never prints 10:29
nine because that runs before you discard that candidate
MasterDuke yep 10:30
brrt good * 10:34
jnthn MasterDuke: My idea for the discarded thing was that sp_fastinvoke_* would check the discarded property 10:37
And if it's set then
1. We're in the caller currently, so that is the specialization that also needs to go away
MasterDuke in MVM_frame_invoke i could NULL the spesh_cand that's been passed if it's been discarded and let it try to find a new one here github.com/MoarVM/MoarVM/pull/1426...c7a0abR495
jnthn 2. We don't actually enter the specialization
MasterDuke: That's part 2 of what I just mentioned. I think for part 1 you could do it in frame.c too, just be sure we only catch the sp_fastinvoke case 10:38
I mean, a late-bound call in a specialized caller, that isn't linked to a particular specialization, does not require us to drop the caller specialization
MasterDuke oh, part 1 wouldn't be in interp.c? 10:39
jnthn You'd have to repeat it 5 times there 10:40
I think only sp_fastinvoke calls the invoke function in frame.c complete with a spesh candidate
So we could probably handle it there 10:41
oh, also: not in interp.c because it'd also need repeating for the JIT
MasterDuke right
speaking of jits, got an M1 yet brrt? 10:42
nwc10 I hope not, and maybe I hope so 10:43
in that I don't want to put any pressure on anyone
and an M1 is a distraction from x86_64
but, "also thinking about aarch64" might tease out some lurking portability assumptions
brrt MasterDuke: no M1 yet 10:59
nine jnthn: so you don't think it'd be worth the trouble to manage the caller specializations from within spesh, i.e. avoid the runtime branch?
brrt and frankly I can't justify the expense of an apple, though a raspberry might be doable 11:00
but I don't know what the architecture/ABI differences are
(and I think that an extension to include aarch64 will cause a major rework of JIT internals, so I'm .... looking forward to it, but I also am not sure when I'm going to find that kind of time) 11:01
jnthn nine: It may be, but it also needs quite a bit of new machinary, whereas this approach lets us have the presumably larger win (getting rid of bad specializations) sooner 11:02
It's also presumably a quite predictable branch
nine I have to admit that I have no idea how branch prediction in CPUs actually works :) 11:03
MasterDuke jnthn: not quite sure how to do part 1 in MVM_frame_invoke. check the outer? 11:04
nine: i recently watched an interesting interview with jim keller and branch prediction came up. tldr; take the same branch as last time gets something 85% correct, modern cpus have essentially a mini neural net to get better than that 11:05
nine MasterDuke: oh, interesting! 11:06
jnthn MasterDuke: No. At the start of MVM_frame_invoke you are *still in the caller* :) 11:21
I think since sp_fastinvoke_* is the only thing that passes a non-NULL spesh candidate argument, you can just go on the NULLness of that argument to know you are considering such a case 11:22
MasterDuke so this is odd. i added `if (spesh_cand && spesh_cand->body.discarded) { fprintf(stderr, "oops, discarded\n"); spesh_cand = NULL; }` the line before here github.com/MoarVM/MoarVM/pull/1426...c7a0abR495 11:24
it never prints
nor does the later if discarded print oops 11:25
but if i comment out the setting spesh_cand to NULL...both prints happen 688k times 11:27
and even when setting to null there are 688k deopts 11:28
11:37 brrt left
MasterDuke btw, merge github.com/MoarVM/MoarVM/pull/1433 now so it has a week before the release? 11:39
11:52 patrickb joined
jnthn +1 on the libuv merge, I think 11:54
MasterDuke just merged it 11:55
12:40 zakharyas left 13:44 zakharyas joined
lizmat has just bumped MoarVM to get the latest version of libuv 14:36
14:47 lucasb joined 15:08 domidumont joined
dogbert11 thx for approving the libuv PR 15:52
lizmat and yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2021/02/15/2021-07-easy-hard/ 16:17
16:21 domidumont left
dogbert11 lizmat++ 16:22
16:56 patrickb left
MasterDuke ok, so not sure what was happening before. but now i have `if (spesh_cand && spesh_cand->body.discarded) { fprintf(stderr, "oops, discarded\n"); spesh_cand = NULL; }` and it gets hit 688k times 17:01
interestingly, if i turn off all the logging and such, the example is now ~0.2s slower. ~2.6s on master, ~2.8s on my branch 17:20
i'm obviously still not doing something i should be doing, because it shouldn't be deopting 688k times 17:21
nine Have you implemented the checks in sp_fastinvoke*? 17:25
MasterDuke no, i thought the plan was to do it in MVM_frame_invoke if spesh_cand is non-NULL, since only the sp_fastinvoke_* ops pass one in 17:27
nine or that...
18:28 domidumont joined 18:44 domidumont left 18:45 brrt joined
nwc10 past me left present me beer in the beer fridge. I figure I should arrange the to return the favour to future me 18:57
nine must be good to be you :D 18:58
brrt I think the expression is to 'pay it forward' - you got if from past you, now you provide to future you? 19:07
anyway.
metaphors
19:31 zakharyas left
MasterDuke hm, i would want to evict the candidate out of the spesh slot if it's set to discarded, wouldn't i? 22:50
22:52 brrt left
MasterDuke huh. if i check the spesh_cand in the sp_fastinvoke_* ops in interp.c they're never set to discarded 23:07
23:52 linkable6 left, evalable6 left 23:53 evalable6 joined 23:55 linkable6 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!