| IRC logs at
Set by AlexDaniel on 12 June 2018.
00:07 Kaiepi left, Kaiepi joined 00:58 pamplemousse joined 01:41 pamplemousse left 01:42 pamplemousse joined 01:47 pamplemousse left 02:10 pamplemousse joined
AlexDaniel MasterDuke: I just tested it on master, I think the issue is still there 02:53
MasterDuke: 02:55
03:11 pamplemousse left
MasterDuke AlexDaniel: huh. guess we need to bisect while applying a patch 06:43
AlexDaniel I'm not in the mood today :D 06:44
MasterDuke i might give it a go in a bit 06:49
nine If rakudo 2020.02.1 runs on MoarVM master, bisecting that ought to be trivial 07:48
MasterDuke doesn't look like it `Cannot auto-decontainerize argument at gen/moar/stage2/QASTNode.nqp:410 (/home/dan/Source/perl6/r/install/share/nqp/lib/QASTNode.moarvm:new)` 07:53
huh. i get a time of 7.5s at HEAD, but 6.8s at 2020.02.1 (without the patch) 07:59
08:00 Altai-man_ joined
MasterDuke hm, 5.3s at 2020.02.1 *with* the patch 08:01
AlexDaniel MasterDuke: yeah, sounds about right
I mean, I'm seeing the same 08:02
nine Well, we do know that rakudo master is a lot slower than 2020.02.1 in general 08:05
MasterDuke oh, right. forgot about that 08:06
so i guess all i need to check is if HEAD minus the patch is slower than HEAD 08:10
yeah. rakudo at HEAD, with MoarVM at HEAD~2 (i.e., minus the patch), is 9s. so 1.5s speedup from the patch 08:22
nine So the patch definitely helps. But does it fix the scaling issue? 08:23
MasterDuke easy way to test? 08:24
08:34 zakharyas joined
AlexDaniel nine: no, it doesn't 08:50
or… well… it depends?
that's the graph on HEAD: 08:51
so clearly there is a scaling issue 08:52
but if it's faster now then it did help somewhat
MasterDuke what does it look like at HEAD minus the patch?
AlexDaniel give me a few minutes… :) 08:53
08:57 sena_kun joined, AlexDaniel left 08:58 AlexDaniel joined, AlexDaniel left, AlexDaniel joined, Altai-man_ left
MasterDuke hm, how do i pass an `MVMString *` (but not one from a register) to the jit? it complains about MVM_JIT_INTERP_VAR 09:04
oh, `ins->operands[x].lit_i64 = (MVMint64)foo;` perhaps? 09:06
AlexDaniel MasterDuke: weird: 09:16
MasterDuke: that's a 1.5s slowdown from the patch
or maybe from other commits 09:17
I simply tested it on 33f41966c 09:18
linkable6 (2020-04-30) Use a smarter semaphore in Supply.squish
AlexDaniel shrugs
MasterDuke i see a speedup of ~1.5s at 2020.02.01 and at HEAD from the patch, just with slower numbers overall at HEAD 09:38
AlexDaniel MasterDuke: yeah, that's how it should be 09:40
09:42 Kaiepi left 09:43 Kaiepi joined
AlexDaniel MasterDuke: retested, I see roughly the same numbers before and after 09:53
AlexDaniel shrugs even more 09:54
MasterDuke before and after the patch?
AlexDaniel on master HEAD, yeah
on 2020.02.1 it was pretty clear 09:55
MasterDuke it'll depend on memory contention and such, so maybe just something about what mem/cpu and how loaded your system is 09:58
AlexDaniel well I tried to make sure that it's not loaded, but yeah 10:02
MasterDuke i also saved 80ms by jitting getcurhllsym. i might not PR that just yet though, it may go in a bigger PR for stuff that has a template, but no lego jit implementation 10:05
10:20 MasterDuke left 10:36 farcas1982regreg left
lizmat MasterDuke: smaller commits bisect better :-) 10:41
tellable6 lizmat, I'll pass your message to MasterDuke
lizmat MasterDuke: especially related to hard to trace bugs in the JIT
tellable6 lizmat, I'll pass your message to MasterDuke
10:47 Ven`` joined 10:56 Altai-man_ joined 10:57 Ven`` left 10:58 sena_kun left 11:38 Ven`` joined 11:49 farcas1982regreg joined 11:55 MasterDuke joined 12:15 farcas1982regreg left 12:17 farcas1982regreg joined
MasterDuke . 12:21
tellable6 2020-05-01T10:41:04Z #moarvm <lizmat> MasterDuke: smaller commits bisect better :-)
2020-05-01T10:41:29Z #moarvm <lizmat> MasterDuke: especially related to hard to trace bugs in the JIT
MasterDuke lizmat: yeah, i usually do a commit per op. but i'm going to do a PR for a bunch of them 12:22
12:41 pamplemousse joined 12:57 sena_kun joined 12:58 Altai-man_ left 13:19 farcas1982regreg left 14:08 farcas1982regreg joined 14:56 Altai-man_ joined 14:58 sena_kun left 16:42 Ven`` left 16:57 sena_kun joined 16:59 Altai-man_ left 17:01 zakharyas left
nine MasterDuke: where do you get that MVMString from if it's not a register? Mind that the GC may invalidate that pointer, so it's usually not a good idea to put that pointer directly into the generated code. 17:34
MasterDuke nine: 17:54
nine MasterDuke: ok, this particular string seems safe 18:08
jnthn That's risky without a check that the point is in gen2
The typical way would be to stick it in a spesh slot and load that 18:09
Those get GC-marked
MasterDuke i based it off of does the first branch there have the same problem? 18:13
timotimo looks to me like it only uses the string to call get_config_for and after that it's not used any more 18:43
MasterDuke that's in the other branch 18:45
timotimo you mean using hll_config? 18:47
MasterDuke line 2293 goes directly to 2303
timotimo that shouldn't be a problem, hlls are malloced and don't move 18:48
and shouldn't be freed either, i would hope
MasterDuke so hllize(for)? is ok, but what i did for getcurhllsym isn't? 18:49
timotimo yeah, that's a VMString that will move, potentially, though shouldn't 18:50
MasterDuke ah, ok 18:55
18:56 Altai-man_ joined
MasterDuke i don't know anything about sticking stuff in spesh slots. know of any examples off hand? 18:56
timotimo i don't know if anything other than spesh/ can do that 18:58
18:59 sena_kun left 19:04 farcas1982regreg left 19:18 Kaiepi left 19:19 Kaiepi joined 19:22 Kaiepi left 19:35 pamplemousse left, pamplemousse joined 19:58 Kaiepi joined 20:57 sena_kun joined 20:59 Altai-man_ left 21:32 pamplemousse left 21:34 Kaiepi left, Kaiepi joined 21:35 Kaiepi left, Kaiepi joined 21:48 farcas1982regreg joined 22:07 reportable6 left, coverable6 left, quotable6 left, leedo left, reportable6 joined, coverable6 joined, quotable6 joined 22:10 leedo joined 22:49 sena_kun left