Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2017-05-17

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:15 timotimo just randomly tossing out there: "cannot get template for "; 7.8k wval, 5.5k prepargs, 4444 sp_findmeth, 4.1k atpos_i, 3.4k. sp_guardconc, 3k elems, 2.8k die, 2.5k unless_o, 2k smrt_strify, 1.9k getdynlex, 1.7k atpos_o
00:16 timotimo there's a bunch of _i ops in there, too. those should be kind of doable around now?
00:17 timotimo box_1, push_1, getattr_i, lt_i, gt_i, pop_i, ne_i, eqaddr (i count this for reasons), bindpos_i, eq_i
00:17 timotimo eq_i isn't the last one, but that's already only 400 occurences
00:17 timotimo all of this for the core setting compilation
00:20 timotimo i don't quite remember what exact metrics we'd use for "we should leave this for the template jit"
00:29 timotimo if_* and unless_* are jumpy, and i don't think we do stuff across BBs at all?
00:31 timotimo i do see Block{...} stuff, but i expect that's blocks at the assembly level, not the moarvm bytecode level (aka spesh level)
00:37 MasterDuke_ timotimo: doable for the new jit or old?
00:37 yoleaux 15 May 2017 09:04Z <jnthn> MasterDuke_: It'll probably be tricky to make them work in the general case (think native arrays, for example; I'm not immediately sure how we'd make them work in that case). I suspect getting them correct even on simple variables will be a bit tricky. So, maybe some day, but it won't be entirely easy.
00:40 timotimo MasterDuke_: new jit, the old jit had these for ages
00:41 MasterDuke_ good, would have been surprised otherwise
00:42 timotimo i uploaded a "coresettingjitlog.txt.xz" onto the whateverable server
00:42 timotimo if you want to take a look yourself
00:42 timotimo (i don't really understand the output terribly well, either)
00:43 MasterDuke_ and implementing the ops for the new jit means writing those s-expr things brrt has mentioned?
00:44 timotimo aye
00:45 timotimo perhaps at some point a tile would have to be written for something
00:46 timotimo tiles are the things that can turn a piece of s-expr stuff into an actual piece of assembly
00:46 timotimo that's a major part of the secret sauce
00:46 timotimo those s-expr pieces can be tiled over with assembly ops in different ways
00:47 timotimo if we get good cost heuristics for those we can probably get some good assembly code out of the whole thing
00:47 MasterDuke_ but you don't need a new tile for every new bit of s-expr?
00:48 timotimo depends on what you mean by "bit" i guess?
00:49 MasterDuke_ so lt_i and gt_i for example?
00:49 timotimo oh, no
00:49 timotimo s-exprs work in terms of something closer to assembly
00:51 timotimo there's a tile named "cmp" that matches things like (lt reg1 reg2)
00:51 timotimo i forgot how to spell registers at the moment
00:51 timotimo i think i'll go to bed now, i'm pretty tired
00:51 timotimo you can check the contents of src/jit/x64 inside the even_moar_jit branch
00:52 timotimo the .dasc file is code that spits out assembly, the .list is code that tells what an s-expr-piece can look like for the given piece of assembly to be appropriate
00:52 MasterDuke_ so you write lt and gt in terms of cmp and you don't need  a new tile?
00:53 MasterDuke_ later...
00:53 timotimo i think that's how
00:54 MasterDuke_ interesting
00:54 timotimo i've actually forgotten how exactly the eq, lt, gt, ne, le, ge actually get the right piece of assembly chosen
00:56 timotimo okay, bedtime
00:56 timotimo i've stumbled over this exact thing at least once before and brrt had to explain it to me
00:56 timotimo sad that the explanation apparently gone to waste :(
00:57 MasterDuke_ yeah, i should go back and read his blog post again...
00:57 MasterDuke_ good luck with the bed
00:58 timotimo it's an uphill battle
01:00 MasterDuke_ maybe some shims under the legs to level it out? ;)
01:49 ilbot3 joined #moarvm
01:49 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
05:31 brrt joined #moarvm
05:42 domidumont joined #moarvm
06:22 domidumont joined #moarvm
06:25 Geth ¦ MoarVM/even-moar-jit: 417055e59c | (Bart Wiegmans)++ | 2 files
06:25 Geth ¦ MoarVM/even-moar-jit: Do not enqueue transfers without inbound registers
06:25 Geth ¦ MoarVM/even-moar-jit:
06:25 Geth ¦ MoarVM/even-moar-jit: Enqueuing unexecutable transfers breaks the required transfers
06:25 Geth ¦ MoarVM/even-moar-jit: mechanism as we would count more transfers as executed than were
06:25 Geth ¦ MoarVM/even-moar-jit: actually done.
06:25 Geth ¦ MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/417055e59c
06:25 Geth ¦ MoarVM/even-moar-jit: 983ecd5de7 | (Bart Wiegmans)++ | 2 files
06:25 Geth ¦ MoarVM/even-moar-jit: Add wval template
06:25 Geth ¦ MoarVM/even-moar-jit:
06:25 Geth ¦ MoarVM/even-moar-jit: As a function that returns a value, interesting correctness test
06:25 Geth ¦ MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/983ecd5de7
06:30 domidumont joined #moarvm
06:34 Ven joined #moarvm
07:37 brrt joined #moarvm
07:38 brrt timotimo: that is pretty much all correct, yes
07:39 brrt i'm now trying atpos_o and unsurprisingly, stuff blows up
07:39 brrt i'll figure out why yet :-)
07:41 brrt .tell MasterDuke: you write it in terms of one of the expr ops (src/jit/expr_ops.h) and those are matched to t iles
07:41 yoleaux brrt: What kind of a name is "MasterDuke:"?!
07:41 AlexDaniel joined #moarvm
07:42 brrt .tell MasterDuke  in this case lt, gt, eq etc are the expr ops, cmp is the tile that can compile all of them (because its the same machine-code instruction
07:42 yoleaux brrt: I'll pass your message to MasterDuke.
07:48 zakharyas joined #moarvm
07:52 zakharyas joined #moarvm
08:15 domidumont1 joined #moarvm
08:32 robertle joined #moarvm
08:39 nwc10 joined #moarvm
09:55 robertle joined #moarvm
11:55 timotimo ah, i missed the expr ops, that'd be why i didn't get it
12:27 domidumont joined #moarvm
12:42 brrt :-)
12:43 brrt okay, i'm going to try and figure out why atpos_o and elems explode so hard
13:17 timotimo when we have common subexpression extraction, we'll be able to make virtual repr calls on the same object consecutively cheaper, right?
13:17 timotimo because the repr struct only has to be looked up once?
13:23 brrt joined #moarvm
13:25 brrt in theory, but no
13:25 brrt in theory *yes
13:25 brrt because, if you call a function, you're going to spill your live values anyway
13:26 timotimo ah, hmm.
13:26 timotimo well, hopefully we'll be able to devirtualize a whole lot of calls in spesh anyway
14:26 FROGGS joined #moarvm
14:36 brrt the improved jit bisect works really pretty smoothly, if i do say so myself
14:36 timotimo sweet
14:36 Zoffix awesome
14:37 timotimo does that mean you were able to figure out atpos_o and elems? :)
14:43 brrt well, haven't had much time for it yet
14:43 brrt but it does cut down on the search spcae to a large extent
14:44 brrt i mean, i now know that elems() is broken by itself, and i know which frame that first manifets
14:45 domidumont joined #moarvm
15:02 timotimo cool
15:20 brrt joined #moarvm
15:42 brrt joined #moarvm
15:58 zakharyas joined #moarvm
16:12 TimToady joined #moarvm
16:38 AlexDaniel joined #moarvm
17:41 robertle joined #moarvm
18:49 domidumont joined #moarvm
20:50 AlexDaniel joined #moarvm
21:06 chatter29 joined #moarvm
22:25 AlexDaniel joined #moarvm
23:06 Voldenet joined #moarvm
23:06 Voldenet joined #moarvm

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary