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