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.
timo are you doing anything to counteract thermal throttling and such? 00:01
jnthnwrthngtn timo: Hmm. How much of an issue is that on a desktop machine where I'm doing nothing except running this (because I'm actually shelled into it from another machine so I can really let it just do these measurements)? 00:03
timo hmm, it's probably fine? not sure if you have lm_sensors set u or something 00:09
jnthnwrthngtn I'm doing 100 runs each time to make the histogram, and have just repeated that 3 times with the same configuration and got 55%, 58%, 55% 00:32
I have a bunch of changes, every one giving > 60% (around 64%) success rate at obtaining something around the best time we get. 00:34
Every measurement I've obtained for combining any two of those (I've tried all permutations now) is around 55%.
Each of the changes seems reasonable in the sense that it addresses a potential issue that could cause worse data for the specializer to use to make decisions. 00:35
I originally thought I was looking at a range of problems that each contribute to missed optimization opportunities, but that doesn't make seem to fit if combining them doesn't add up to a better overall result. 00:37
Anyway, enough for today. 00:38
timo right, that is pretty odd 00:45
MasterDuke do we know where and how hash randomization effects optimization? is there some way we could minimize that? different data structure? 08:30
nine It certainly does. The order in which spesh plans are created or processed is dependent on hash ordering 08:42
That's why it's good to disable hash randomization when spesh bisecting 08:44
nine Ah, found my strange GC issue! I just have to restore tc->cur_frame->return_type after a callback. Otherwise it would have been set to MVM_RETURN_VOID by finalize_handler_caller and we never write the return value to its target register. 09:09
MasterDuke huh, this is kind of annoying. i'm trying to rebase remove_spesh_optimization_if_it_has_too_many_deopts, and just realized in the merge conflicts it just shows a conflict with HEAD, but i think HEAD is just whatever commit it's currently working it's way through merge 09:17
*through merging
it doesn't give me the actual hash of that commit
doh. i'm thinking of it backwards. it replays my commits on top of HEAD 09:31
Geth MoarVM/new-disp-nativecall: 4 commits pushed by (Stefan Seifert)++ 11:10
MasterDuke well, remove_spesh_optimization_if_it_has_too_many_deopts has been rebased to master and compiles. now there's just the little matter of the segv in the nqp build... 12:58
Geth MoarVM/new-disp-nativecall: 50696c39aa | (Stefan Seifert)++ | 4 files
No longer allocate an argument array for generic native calls

Add a new variant MVM_nativecall_dispatch which understands the new dispatcher argument passing convention to avoid allocating and populating an argument array for every call.
13:25
MasterDuke hm, this spesh candidate has num_spesh_slots = 1432169616, that seems a little high...
nine Great news! With this ^^^ the boot-foreign-code dispatch terminal based NativeCall is now faster than the version that dispatches to the generated function bodies. csv-ip5xs.pl is 13.883s vs 14.440s before. 13:26
MasterDuke what was it pre-new-disp? 13:29
nine 14.442s with all it's JIT glory 13:34
MasterDuke very cool
ugh, think i'm going to have to break out rr. the spesh candidate pulled from tc->cur_frame->effective_spesh_slots is not well-formed 13:44
dogbert17 nine++ 13:49
dogbert17 nine: perhaps I've made a mistake when building your branch but one test (#9) in t/04-nativecall/02-simple-args.t fails for me 14:13
and I have made a mistake, grrr 14:14
heh, now it SEGV's instead 14:20
==3028465==ERROR: AddressSanitizer: heap-use-after-free on address 0x6040003a6210 at pc 0x7f7902b81c65 bp 0x7fff928eeed0 sp 0x7fff928ee678 14:23
READ of size 1 at 0x6040003a6210 thread T0
#0 0x7f7902b81c64 (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xd6c64)
#1 0x7f78fbf1532a in CheckString t/04-nativecall/02-simple-args.c:78
nine dogbert17: no mistake. That's an open issue still. It's not actually a regression, just a longstanding bug that was hidden before. 14:32
Without this bug, I'd probably have merged the first commit of the raku already, as it fixes the performance regression, even though it does not yet take full advantage of the new possibilities 14:39
This requires a similar fix to Proxy support (the other open issue). Both require checking an argument's type and calling a method on it to obtain the actual value that we want to pass on. I think the latter requires dispatch resumption. 14:44
dogbert17 so more work has to be done then 14:45
nine always, always 15:01
MasterDuke if an op has an operand that i changed from being an `int16` to an `sslot`, and i want to get that operand, `&(ins->operands[3])` should change to just `ins->operands[3]`?
hm, maybe not, because setting its value is still just `operand->lit_i16 = <foo>`, right? 15:06
nine right 15:17
MasterDuke the branch is currently rebased locally and i'd like to push it. however, i'd like the current branch on the remote to stay as is so i can easily see the original changes i made. i can just push to a new branch on the remote, correct? 15:41
Geth MoarVM: MasterDuke17++ created pull request #1561:
Remove a spesh optimization if it has too many deopts (rebased after new-disp)
16:41
MasterDuke ^^^ segfaults pretty much right away in the nqp build with a bad spesh candidate, but i'm not sure why, the changes look correct. rr is dying for me, so haven't been able to track it down yet 16:44
MasterDuke oh. `spesh_cand->body.jitcode` is 0xffffffff00000004, that looks suspicious 17:00
nine very 18:23
MasterDuke i still don't see anything wrong in the diff (or missing), but i guess i'll have to reboot and see if that fixes rr 18:30
Nicholas nine: ASAN is very excited by t/04-nativecall/02-simple-args.t 18:52
paste.scsys.co.uk/595985