|
github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm 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: github.com/rakudo/rakudo/issues/36...-622224145 | 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: user-images.githubusercontent.com/...dc5082.png | 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: user-images.githubusercontent.com/...e49ee8.png | 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) github.com/rakudo/rakudo/commit/33f41966cf 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: gist.github.com/MasterDuke17/f7907...3ed602fd8a | 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 | ||
| *pointer | |||
| 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 github.com/MoarVM/MoarVM/blob/mast...2282-L2306 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
|
|||
