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
00:02 reportable6 left
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
00:15 frost joined
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
01:05 reportable6 joined 01:21 ggoebel joined 01:26 ggoebel left 02:26 unicodable6 left, evalable6 left, statisfiable6 left, linkable6 left, nativecallable6 left, releasable6 left, quotable6 left, coverable6 left, sourceable6 left, benchable6 left, squashable6 left, bisectable6 left, bloatable6 left, reportable6 left, greppable6 left, committable6 left, tellable6 left, shareable6 left, notable6 left 02:27 unicodable6 joined, nativecallable6 joined, linkable6 joined, shareable6 joined, coverable6 joined, committable6 joined 02:28 bloatable6 joined, quotable6 joined 02:29 benchable6 joined 02:35 leont left 02:37 leont joined 03:01 frost left 03:05 frost joined 03:26 greppable6 joined 03:28 tellable6 joined 03:29 evalable6 joined, statisfiable6 joined 04:26 reportable6 joined 04:27 squashable6 joined 04:28 bisectable6 joined 04:29 releasable6 joined 05:26 notable6 joined 06:02 reportable6 left 06:04 reportable6 joined 07:04 reportable6 left, quotable6 left, statisfiable6 left, linkable6 left, nativecallable6 left, releasable6 left, benchable6 left, bloatable6 left, shareable6 left, bisectable6 left, coverable6 left, committable6 left, tellable6 left, squashable6 left, evalable6 left, unicodable6 left, greppable6 left, notable6 left, nativecallable6 joined, benchable6 joined 07:05 unicodable6 joined 07:06 tellable6 joined, bisectable6 joined, releasable6 joined, notable6 joined, squashable6 joined 07:07 linkable6 joined 07:27 sourceable6 joined 08:04 bloatable6 joined, committable6 joined 08:05 greppable6 joined
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
09:04 quotable6 joined 09:05 shareable6 joined 09:06 coverable6 joined 09:07 evalable6 joined
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
09:41 patrickb joined 10:04 statisfiable6 joined 10:07 reportable6 joined
Geth MoarVM/new-disp-nativecall: 4 commits pushed by (Stefan Seifert)++ 11:10
11:23 ggoebel joined 11:54 ggoebel left 12:02 reportable6 left
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
13:03 reportable6 joined
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.
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
13:30 sena_kun joined 13:33 Altai-man left
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
13:46 discord-raku-bot left, discord-raku-bot joined
dogbert17 nine++ 13:49
13:50 discord-raku-bot left, discord-raku-bot joined 14:02 frost left
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
15:22 linkable6 left, evalable6 left, evalable6 joined 15:24 linkable6 joined 15:38 sena_kun left 15:39 sena_kun joined
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
15:43 Altai-man joined 15:44 sena_kun left 15:54 Altai-man left, sena_kun joined
Geth MoarVM: MasterDuke17++ created pull request #1561:
Remove a spesh optimization if it has too many deopts (rebased after new-disp)
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
16:47 rypervenche joined
MasterDuke oh. `spesh_cand->body.jitcode` is 0xffffffff00000004, that looks suspicious 17:00
18:02 reportable6 left 18:03 linkable6 left 18:06 linkable6 joined
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
18:41 vrurg left 18:42 vrurg_ joined 18:43 japhb left, japhb joined 18:52 MasterDuke left
Nicholas nine: ASAN is very excited by t/04-nativecall/02-simple-args.t 18:52
19:03 MasterDuke joined, reportable6 joined 19:52 jdv left, jdv joined 20:15 patrickz joined 20:39 cog__ joined, cognominal_ left 20:40 [Coke] left 20:41 cog__ joined, [Coke]_ joined 20:48 ggoebel joined 21:21 ggoebel left 21:32 ggoebel joined 23:00 vrurg_ is now known as vrurg 23:12 patrickz left 23:14 patrickb left 23:22 [Coke]_ is now known as [Coke] 23:52 ggoebel left