github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
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
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
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
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
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
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)
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
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
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
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
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
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
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
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
MasterDuke '1 = STable (Iterator)' 22:45
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

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!