|
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. |
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 | |
|
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) |
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 | |
|
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 | |
| paste.scsys.co.uk/595985 | |||
|
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
|
|||