japhb nine: When you say "really seems to help performance", what scale of improvement are you talking about? 00:10
Geth MoarVM/spesh_lex_vivify_checks: e5750c5961 | (Timo Paulssen)++ | 8 files
WIP on removing lex vivification checks

in theory we can know when a lex is guaranteed to have already been accessed before by looking at the dominator tree.
However, this still runs into the safety check in the sp_getlex_live_o op while compiling rakudo.		 00:36
MoarVM: MasterDuke17++ created pull request #784:
Un-bitrot tools/parse_jitgraph.p6		 02:25
MoarVM: c602235ef7 | MasterDuke17++ | tools/parse_jitgraph.p6
Un-bitrot tools/parse_jitgraph.p6

Convert first-index(...) to first(..., :k).		 02:54
MoarVM: 9df7c1645a | (Zoffix Znet)++ (committed using GitHub Web editor) | tools/parse_jitgraph.p6
Merge pull request #784 from MasterDuke17/fix_parse_jitgraph

Un-bitrot tools/parse_jitgraph.p6
02:56 ilbot3 joined
MasterDuke looks like Geth is down, i just created github.com/MoarVM/MoarVM/pull/785 05:16
Zoffix: Geth seems to be down 05:18
05:30 dalek joined, Geth joined, synopsebot_ joined, p6lert joined
Geth MoarVM: MasterDuke17++ created pull request #785:
Add JIT template for atkey_o		 05:33
05:35 synopsebot joined, SourceBaby joined 05:50 statisfiable6 joined
Geth MoarVM: a04d1099b0 | (Aleks-Daniel Jakimenko-Aleksejev)++ | build/setup.pm
Revert "Try to use egcc when compiling on OpenBSD"

This reverts commit 28eaf97d05d18e6e4ce528f6d723022609e8338b.
  See rakudo/rakudo#1420		 07:01
synopsebot RAKUDO#1420 [open]: github.com/rakudo/rakudo/issues/1420 [regression][⚠ blocker ⚠] FreeBSD issues
08:21 Zoffix joined
Zoffix Is it expected for `getlexref_i` to be a lot slower than `getlex`? 08:21
Also are there any docs that could explain why/when I'd want getlexref_i rather than plain getlex 08:23
08:27 Util joined 08:39 domidumont joined 08:45 domidumont joined
samcv Zoffix: i don't know. but if you find out. add something to nqp op docs please 09:40
Zoffix I'll try 09:41
Was asking because I'm 90% sure getlexref_i instead of getlex is what's causing R#1416 10:03
synopsebot R#1416 [open]: github.com/rakudo/rakudo/issues/1416 [perf] nqp::if((my int $n),1) is 4.5x slower than non-native version
Zoffix Gonna give up on it for now
\o
10:03 Zoffix left
nine japhb: it's not much, but it's clearly measurable which is nice considering how little time I spent on my first 2 templates 10:14
When's the release gonna happen? Looking forward to merging stuffs :) 10:16
samcv nine: should happen when i wake up tomorrow 10:57
nine samcv: oki :) 10:58
10:58 domidumont joined
lizmat hmmm... moarvm.org still on 2017.09 ? 11:43
11:48 releasable6 joined 12:36 greppable6 joined, benchable6 joined, coverable6 joined, reportable6 joined
timotimo nine: what benchmarks are you using? 13:03
zoffix, lexicalref is a mechanism that allows us to treat a native value stored in a lexpad as if it were a read-writable container we can pass around. the lexicalref that gets created holds a reference to the frame in question and any access to it acts like getlex from the frame it originated in. this means a couple of things for performance, one is that the frame it's taken for needs to move off of the call 13:08
stack and onto the heap
that's a costly operation on its own
but of course there's also the overhead of allocating the lexicalref in the first place
nine timotimo: I'm mostly interested in csv-ip5xs.pl of course :) 13:17
timotimo that's fair
nine timotimo: why do we need all that for natives but not of high level lexicals?
timotimo high level lexicals are references to scalars, we can just pass the scalars around 13:18
jnthn Effectively, the reference model is <storage location> --Pointer--> Scalar --Pointer--> Value 13:35
The value model is that the storage location directly holds the value 13:36
And if we need a reference to it, then we allocate a reference object that points to the container and carries the index/key/whatever
timotimo after inlining and recalculating the dominance tree we should try rediscovering facts about the inlined blocks only, then we can do an extra pass of optimization to do Good Things with that 13:37
nine Wouldn't we know at compile time that we need such a reference object?
jnthn Sometimes.
get*ref_* is always safe: it works as an r-value or and l-value 13:38
So we pretty much always produce the ref scope in the initial QAST tree 13:39
The QAST -> MAST phase, however, turns a great deal of those into the non-ref case, because it knows an r-value is needed
What it cannot do for us is deal with things like Perl 6 native arrays
That is, where we call .AT-POS 13:40
Since .AT-POS could be called in either situation
Thankfully, we're quite good at inlining these days
And so we'll be able to deal with such cases in spesh 13:41
I think we've also so far done very little about optimizing use of native references in spesh 13:42
But I designed it to let us spesh away most of the branching/checking there also
Also - and this is the easiest win - there may be further places in QAST -> MAST that we can make a static deduction, but where we aren't 13:44
MasterDuke kind of unrelated, but hasn't there been some talk of removing MAST? or was that QAST? 13:48
timotimo at some point we could directly generate mbc from nqp
i.e. with buf8 and push and append and such 13:49
MasterDuke so stage mbc would disappear and just end up part of stage optimize?
jnthn MasterDuke: Yes, I mentioned it could be done as a real-world test case for improved APIs for working with binary data 13:50
No, stage mast and stage mbc would become one
We'd also hugely reduce memory use during compilation
MasterDuke right, forgot there was both mast and mbc. reduced memory during compilation would be very cool 13:52
timotimo right, the memory use peaks because we first have to have every single mast object allocated before we can pass it off to the compiler 13:53
if we do it in one go we can likely compile mast directly and clean up parts we've just finished
jnthn Indeed 13:54
MasterDuke is that an all-or-nothing change? 13:55
nine Seems like I got the expression tree compiler to segfault... 13:57
MasterDuke i.e., could we just directly generate parts of nqp to mbc? 14:01
nine MasterDuke: I guess one could introduce special MAST nodes that just forward already generated bytecode 14:03
MasterDuke hm 14:05
jnthn MasterDuke: I'd probably do it by having both the current and new one in there, and have an env var to control it
Then we can slowly work our way through being able to do the NQP test suite, Rakudo test suite, compiling NQP, etc. 14:06
MasterDuke jnthn: sorry, current and new one what? MAST node?
jnthn Current QAST -> MAST -> MBC compiler, and new QAST -> bytecode one
Note that NQP's bootstrap build would imply that you end up using any changes you do immediately, which means you can't rule out that a problem is because of a mis-compile in the compiler rather than just the compiler miscompling :) 14:07
So I think retaining the current one and having a new one that is opt-in until it's ready to be a full replacement is the best way 14:08
MasterDuke ah, thanks 14:09
14:14 bisectable6 joined
nine How I wish extops would have never been a thing... 14:45
Geth MoarVM/inline_in_place: 9 commits pushed by (Stefan Seifert)++ 14:51
MoarVM/inline_in_place: e9fe021cde | (Stefan Seifert)++ | src/jit/log.c
Fix segfault in JIT bytecode dumper on code without static frame
 14:58
nine jnthn: any hint how to approach retainment of facts when inlining? 15:27
timotimo we can't retain facts when inlining, they aren't there to begin with 15:28
nine Could we rediscover them? Or some like wval known values?
timotimo we'd have to rediscover them, yeah 15:29
we might want to make sure not to overwrite facts we've changed since the initial discovery phase
that's why i was suggesting to only discover facts in inlined blocks, and to do it before the second pass after recalculating the SSA form
recompute dominance* 15:30
(not the whole SSA form)
with that, we will want to buff up the second pass, too. 15:35
nine Could it really be just a single line? 15:37
MVM_spesh_facts_discover(tc, inline_graph, p);
timotimo i think it'll need more care than that, but try it out
nine With that we can inline JIT compiled native calls
timotimo depending on where that goes, does it access the right places for facts known about the inliner? 15:38
nine I have no idea. It just works when I put that in src/spesh/optimize.c:1631 before MVM_spesh_get_facts(tc, g, code_ref_reg)->usages++; MVM_spesh_inline(tc, g, arg_info, bb, ins, inline_graph, target_sf, code_ref_reg); 15:39
timotimo ah, that looks somewhat safe, but it'll leave out a bunch of things we know 15:41
i don't think we pass any info about the arguments we're "calling" the inlinee with
jnthn I think probably we'd want to propagate any facts we have about arguments going into the inline before calling MVM_spesh_facts_discover on the inline graph, so it can propagate such information further 15:54
Additionally, we'd want to look at guards and set facts based on what the guards are enforcing, when doing fact discovery on "inline mode" 15:55
Though we perhaps don't need any mode flag at all
15:55 Kaiepi joined
jnthn In that sp_log won't be there in the inlinee's bytecode, and guards won't be there in the original bytecode we discover facts on 15:55
Of coures, those 2 steps are additional ones to make the facts more complete 15:56
*course 15:57
So no problem just to pop a MVM_spesh_facts_discover call in initially
timotimo say, we don't register the inlined BBs in the dominator tree, right? but the dominator tree is how the optimizer visits stuff
jnthn We do before the second_pass
I'm pretty sure we do, anyway 15:58
I think that's one of the things I fixed up last summer
timotimo right, so stuff that wants to handle inline boundaries will have to go into the second pass
yes, it recalculates the dominators there
jnthn Yes, I'd assumed that we'd do such things in pass 2 :)
timotimo we can probably move a bunch of stuff over
rather than re-doing many things
though the first pass is already just a big switch on ops that mostly just directly calls our optimization functions 15:59
so there isn't much duplication even if we do stuff multiple times
15:59 zakharyas joined 16:42 Ven`` joined
MasterDuke does jg_append_primitive ( github.com/MoarVM/MoarVM/blob/mast...raph.c#L15 ) have something equivalent in the expr jit? 16:43
timotimo don't think so, why? 16:49
16:52 Ven`` joined
timotimo the primitive ops rely on emit.dasc, i.e. snippets of asm that rely on every value residing on the heap and having to be loaded before and stored after working 16:52
MasterDuke there are a whole lot of ops that just call that in the switch in graph.c 16:56
one of which is sp_findmeth, the most common 'Cannot get template for:' when building rakudo 16:57
7890 of them
timotimo yeah, look at emit.dasc to see the implementation of the primitive ops
MVM_jit_emit_primitive 16:58
MasterDuke k, thanks
17:31 Ven`` joined 17:32 AlexDaniel joined
Geth MoarVM/inline_in_place: 812480036d | (Stefan Seifert)++ | 3 files
Run basic facts discovery on inlined code

This is enough to discover the known value of wvals. With these values we can unblock JIT compilation of inlined native calls.		 17:34
17:39 zakharyas joined 17:44 zakharyas joined 17:56 travis-ci joined
travis-ci MoarVM build failed. Samantha McVey 'Merge pull request #781 from samcv/ucd-critic 17:56
travis-ci.org/MoarVM/MoarVM/builds/330705279 github.com/MoarVM/MoarVM/compare/a...4869e37bcb
17:56 travis-ci left
MasterDuke .tell brrt line 104 of github.com/MoarVM/MoarVM/blob/mast...t/tiles.md has a sentence that doesn't end 18:36
yoleaux MasterDuke: I'll pass your message to brrt.
18:41 nativecallable6 joined
timotimo This approach has been abandoned after it was clear 18:41
^- this one?
19:36 quotable6 joined
jnthn It was so clear there was no reason to explain it :P 20:21
20:25 lizmat joined 20:51 evalable6 joined 21:13 yoleaux joined
MasterDuke a bit of a delayed response, but yeah, that was the sentence i meant 21:36
timotimo it was clear which one you meant :D
MasterDuke ba-dum-tiss 21:37
21:46 yoleaux joined, mtj_ joined 21:51 travis-ci joined
travis-ci MoarVM build failed. Jonathan Worthington 'Pay attention to return op in cross-HLL inlines 21:51
travis-ci.org/MoarVM/MoarVM/builds/330895302 github.com/MoarVM/MoarVM/compare/a...b2c5f82a83
21:51 travis-ci left 21:57 Kaiepi joined 22:00 mtj_ joined 22:20 yoleaux joined 22:22 squashable6 joined, unicodable6 joined, committable6 joined, bloatable6 joined
samcv .tell pmurias where does it fail? can you show/tell me? thanks! 22:23
ugh yoleaux
22:24 Kaiepi joined 22:31 _Kaiepi joined 22:43 Ven`` joined 23:09 greppable6 joined 23:27 _Kaiepi joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!