|
github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm Set by AlexDaniel on 12 June 2018. |
|||
|
00:02
dogbert17 joined
00:05
dogbert11 left
00:16
dogbert2 joined
00:19
dogbert17 left
00:22
dogbert11 joined
00:23
dogbert2 left
00:33
dogbert11 left
00:51
dogbert11 joined,
Altai-man joined
00:52
dogbert17 joined
00:54
sena_kun left
00:55
dogbert11 left
00:58
dogbert2 joined
01:00
dogbert17 left
02:01
dogbert2 left,
dogbert2 joined
02:14
dogbert11 joined
02:16
dogbert2 left
02:25
dogbert17 joined
02:29
dogbert11 left
02:39
chansen_ joined
03:02
dogbert11 joined
03:05
dogbert17 left
03:12
dogbert11 left
03:37
dogbert11 joined
03:42
dogbert17 joined,
dogbert11 left
03:46
dogbert11 joined
03:49
dogbert11 left,
dogbert17 left
03:50
dogbert11 joined
03:54
lucasb left,
dogbert11 left
03:56
dogbert11 joined
04:01
dogbert17 joined,
dogbert11 left,
dogbert17 left
04:02
dogbert17 joined
04:38
dogbert17 left
04:52
sena_kun joined
04:54
Altai-man left
05:05
dogbert17 joined
06:09
dogbert11 joined
06:12
dogbert17 left
06:18
dogbert11 left,
dogbert11 joined
06:25
dogbert17 joined
06:29
dogbert11 left
06:33
dogbert11 joined
06:37
dogbert17 left
06:38
dogbert11 left,
dogbert11 joined
06:50
dogbert11 left
06:51
Kaiepi joined
06:52
dogbert11 joined
07:15
Kaiepi left,
Kaiepi joined
|
|||
| nwc10 | good *, #moarvm | 07:31 | |
| Geth | MoarVM/fetch-and-delete: f252843da7 | (Nicholas Clark)++ | 7 files Add OPs fetch_delete_key and MVM_repr_emulate_fetch_delete_key This is the first step for a proof-of-concept "fetch and delete" OP. |
07:40 | |
| MoarVM/fetch-and-delete: 1a69fb0d9b | (Nicholas Clark)++ | 5 files Add MVM_str_hash_fetch_and_delete, to implement fetch_delete_key |
|||
| MoarVM/fetch-and-delete: 288762a5ba | (Nicholas Clark)++ | 4 files JIT for OP_fetch_delete_key Implemented as a variant of OP_atkey_o. |
|||
| MasterDuke | i can never remember, what's the plan for the param_op_* ops? | 08:51 | |
|
08:51
Altai-man joined
08:54
sena_kun left
09:54
Kaiepi left
09:55
Kaiepi joined
09:56
dogbert17 joined
09:59
dogbert11 left
10:54
zakharyas joined
11:01
zakharyas left
11:03
leont joined
11:15
dogbert11 joined
11:18
dogbert17 left,
dogbert17 joined
11:23
dogbert11 left
11:31
Kaiepi left,
Kaiepi joined
11:38
Kaiepi left
11:39
Kaiepi joined
11:41
Kaiepi left
11:43
Kaiepi joined
11:45
Altai-man left
11:48
Kaiepi left
11:55
Kaiepi joined
12:00
dogbert11 joined
12:02
dogbert12 joined
12:03
dogbert17 left
12:05
sena_kun joined,
dogbert11 left
12:06
dogbert17 joined,
dogbert12 left
12:07
dogbert11 joined
12:10
dogbert17 left
12:11
dogbert17 joined
12:13
dogbert11 left
12:16
dogbert11 joined
12:19
dogbert17 left
|
|||
| jnthn | MasterDuke: Not sure what kind of plan would be needed? In specialized code they are usually optmized out based on a known callsite shape; if they are not being, then we could do with figuring out why. | 12:21 | |
|
12:23
dogbert17 joined
12:24
dogbert17 left
12:25
dogbert17 joined,
dogbert11 left
12:26
dogbert11 joined
12:29
dogbert12 joined
12:30
dogbert17 left
12:31
dogbert11 left
12:32
dogbert17 joined
|
|||
| MasterDuke | jnthn: istr they were going away eventually? maybe that's some other ops? anyway, github.com/rakudo/rakudo/blob/mast...#L134-L139 isn't being jitted because of param_op_o when running `say ("a" .. "zz")[*].elems;` | 12:33 | |
| which takes 2.5s for me, compared to 0.02s for `say ("a" .. "zz")[].elems;` | 12:34 | ||
|
12:35
dogbert12 left
|
|||
| MasterDuke | there are 740k deopts in reify-at-least github.com/rakudo/rakudo/blob/mast...m6#L40-L97 but i can't tell why from the spesh log. what should i be looking for? | 12:44 | |
|
12:51
Altai-man joined
12:53
sena_kun left
13:13
dogbert11 joined
13:17
dogbert17 left
13:30
dogbert17 joined
13:33
dogbert11 left
13:46
dogbert11 joined
|
|||
| jnthn | MasterDuke: Nope, no plans for them to go away | 13:47 | |
| Note that @a[] is just the indentity function whereas @a[*] would need to build a new result list, so it's possible that the first actually doesn't even expand the range | 13:48 | ||
|
13:48
dogbert17 left
|
|||
| jnthn | (If it can figure out the elems without doing so) | 13:48 | |
| Altai-man does release | 13:49 | ||
| jnthn | For deopts, you might get more info if you turn on the deopt debug dump (#define at top of deopt.c) | ||
|
14:08
dogbert17 joined
14:10
dogbert11 left
|
|||
| Geth | MoarVM/2020.08: 7fe09419de | Altai-man++ | docs/ChangeLog Update ChangeLog for 2020.08 release |
14:17 | |
| MoarVM/2020.08: f877443fb6 | Altai-man++ | VERSION Bump VERSION for release |
|||
| MoarVM: Altai-man++ created pull request #1338: 2020.08 |
14:18 | ||
| MoarVM: 7fe09419de | Altai-man++ | docs/ChangeLog Update ChangeLog for 2020.08 release |
14:22 | ||
| MoarVM: f877443fb6 | Altai-man++ | VERSION Bump VERSION for release |
|||
| MoarVM: 0e7417add5 | Altai-man++ (committed using GitHub Web editor) | 2 files Merge pull request #1338 from MoarVM/2020.08 2020.08 |
|||
|
14:30
dogbert12 joined
14:32
dogbert17 left
|
|||
| MasterDuke | jnthn: fwiw, `my @a = ("a" .. "zz")[]; say @a[(^@a).pick]; say now - INIT now` takes the same amount of time for both | 14:34 | |
| both [] and [*] | |||
| same amount of time as the previous timings | 14:35 | ||
| i'm being so very clear | |||
| m: my @a = ("a" .. "zz")[]; say @a[(^@a).pick]; say now - INIT now | |||
| camelia | cw 0.03840503 |
||
| MasterDuke | m: my @a = ("a" .. "zz")[*]; say @a[(^@a).pick]; say now - INIT now | ||
| camelia | py 5.62438356 |
||
|
14:37
dogbert17 joined
|
|||
| MasterDuke | just a ton of `Deopt one requested by interpreter in frame 'reify-at-least' (cuid '5415') Will deopt 128 -> 132Completed deopt_one in 'reify-at-least' (cuid '5415') with potential uninlining` | 14:37 | |
|
14:39
dogbert12 left
14:40
zakharyas joined
15:08
lucasb joined
|
|||
| MasterDuke | all but one or two of the deopts are because of sp_guardtype | 15:16 | |
| what's a good way to print an STable to see what types i'm getting? | 15:18 | ||
|
15:19
dogbert11 joined
15:21
dogbert17 left
|
|||
| MasterDuke | 246k got 'Rakudo::Iterator::Gather' but want 'Iterator' | 15:23 | |
| 492k got 'List::Todo' but want 'Iterator' | |||
| src/core.c/List.pm6:587: my class Todo does Iterator { | 15:34 | ||
| src/core.c/Rakudo/Iterator.pm6:1960: my class Gather does Rakudo::SlippyIterator { | 15:35 | ||
| should there be an sp_guarddoes? | |||
| jnthn | No, guards are monomorphic things | 16:10 | |
| The question is not really "how many deopts" but more "what is the proportion of deopts at this point" | 16:11 | ||
| Though those numbers look huge, so I suspect it's making a bad choice to insert a guard at some point along the way | |||
| Probably worth looking at the stats that lead up to that | 16:12 | ||
| MasterDuke | stats in the spesh log? which ones? | 16:35 | |
| jnthn | The ones for the frame that the deopt happens in, although if there's inlining that may be less obvious | 16:36 | |
| You can probably search for something like "Statistics for 'blah'" (I forget exactly how it looks) | |||
| MasterDuke | last entry: Latest statistics for 'reify-at-least' (cuid: 5415, file: SETTING::src/core.c/List.pm6:40) | 16:38 | |
| Total hits: 458 | |||
| jnthn | jnthn.net/papers/2017-spw-deopt.pdf has some info on how these pieces fit together | ||
| The "Logged at offset" section is probably most applicable | 16:39 | ||
| MasterDuke | gist.github.com/MasterDuke17/bd096...7a66f9518f | 16:41 | |
| afk for eating | 16:43 | ||
| jnthn | yeah, I'm about to go cook to; next step though would be to look at the deopt output for the offset it deopts to and try to match it up to the status | 16:44 | |
| *stats | |||
| *too | |||
|
16:52
sena_kun joined
16:54
Altai-man left
|
|||
| nwc10 | oops. I managed to write a regression test that hit one of my assertions. | 17:20 | |
| (on the branch) | 17:21 | ||
| oh, I forgot - I wrote some tests that excited ASAN on master. | |||
| I think, in typign this, it's actually the test that I've just tried to write now. | |||
| oh, no, it was others. | 17:22 | ||
| reading the key and value "through" the iterator after you have deleted the element at the iterator position | |||
| UT Hash doesn't like that. Oops. :-) | |||
| lucasb | sena_kun: thanks for the releases! | 17:26 | |
| The file MoarVM-2020.08.tar.gz from the website directory will be the same pushed on the github release too, right? | |||
| MasterDuke | jnthn: e.g., 'Will deopt 282 -> 350'? some of those values should match the offset values? | 17:41 | |
| so there are 740k 'Will deopt 128 -> 132', but i don't see 128 or 132 in that gist | 17:55 | ||
| or anywhere else in the spesh log | |||
|
18:20
MasterDuke left
18:35
MasterDuke joined
19:28
dogbert17 joined
19:30
dogbert12 joined
19:32
dogbert13 joined,
dogbert11 left
19:35
dogbert17 left,
dogbert12 left
19:42
dogbert13 left,
dogbert13 joined
19:53
dogbert17 joined
19:56
dogbert13 left
19:57
dogbert11 joined
20:02
dogbert17 left
20:05
dogbert17 joined
20:07
dogbert11 left
20:23
dogbert11 joined
20:26
dogbert17 left
20:46
zakharyas left
20:51
Altai-man joined
20:54
sena_kun left
21:05
dogbert11 left
21:08
dogbert11 joined
21:14
dogbert17 joined
|
|||
| jnthn | MasterDuke: It'd be the second number that's interesting here (the one after the ->) as that is the unoptimized bytecode offset. | 21:14 | |
|
21:17
dogbert11 left
21:22
AlexDaniel left
21:23
dogbert17 left,
dogbert17 joined
|
|||
| MasterDuke | jnthn: i see a bunch of '132' in the spesh log, but i'm not sure which are the relevant ones (i.e., `BB 132` obviously isn't, but what about `[Annotation: INS Deopt OSR (idx 7 -> pc 132); line 642]`)? | 21:49 | |
| jnthn | Yes, that one would be | 22:11 | |
| the -> meaning is basically the same in both cases | |||
| pc = program counter = bytecode offset so it's the same unit | 22:12 | ||
| MasterDuke | what about any offset's of 132, even if they're not for reify-at-least? | 22:23 | |
| ah, i see '[Annotation: INS Deopt One (idx 2 -> pc 132; line 41)]' in the before spesh of reify-at-least | 22:24 | ||
| and after | 22:25 | ||
| with 'sp_guardtype r10(3), r10(32), sslot(1), litui32(2)' on the next line | |||
| jnthn | Yes, and you can see what is in sslot(1) (there's a table below the dump) | 22:32 | |
| That'll be the type it was expecting | 22:34 | ||
|
22:39
Kaeipi joined
22:40
Kaiepi left
|
|||
| MasterDuke | '1 = STable (Iterator)' | 22:45 | |
|
22:46
Kaeipi left
|
|||
| MasterDuke | hm, but does that tell us anything i didn't get from the fprintf i added to interp.c? | 22:47 | |
| Deopt one requested by interpreter because of sp_guardtype, got 'Rakudo::Iterator::Gather' but want 'Iterator' | 22:48 | ||
| anyway, off to bed. hopefully can figure some more out tomorrow | 22:57 | ||
| jnthn | Well, now it's "just" a matter of correlating that point in the bytecode with the statistics and with the source code and trying to figure out why it's putting that guard there and why it's a poor choice | 23:05 | |
| 126: | 23:06 | ||
| 2 x type Iterator (TypeObj) | |||
| If it's that one then, well: | |||
| Type tuple 0 | |||
| Type 0: List::Reifier (Conc) | |||
| Hits: 458 | |||
| It's 100% always Iterator *if* we hit that code path, but we hit it so rarely at the point we make the decision it's maybe not representative, but there's nothing so far that tries to make such a judgement | 23:07 | ||
| timotimo | not entirely happy that you have to do so much manual correlation for all this :) | 23:33 | |
|
23:42
Altai-man left
|
|||