Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2016-07-06

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

All times shown according to UTC.

Time Nick Message
00:18 lizmat joined #moarvm
01:01 vendethiel joined #moarvm
01:48 ilbot3 joined #moarvm
01:48 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
01:57 vendethiel joined #moarvm
06:42 domidumont joined #moarvm
07:34 zakharyas joined #moarvm
09:42 brrt joined #moarvm
09:59 zakharyas joined #moarvm
11:03 dalek MoarVM/line_based_coverage_3: 83468b5 | (Daniel Green)++ | tools/parse_coverage_report.p6:
11:03 dalek MoarVM/line_based_coverage_3: Break out percentage into its own column and add some JS+CSS to sort the table
11:03 dalek MoarVM/line_based_coverage_3: review: https://github.com/MoarVM/MoarVM/commit/83468b54ee
11:03 dalek MoarVM/line_based_coverage_3: 641b736 | (Daniel Green)++ | tools/parse_coverage_report.p6:
11:03 dalek MoarVM/line_based_coverage_3: Switch to the non-minified JS
11:03 dalek MoarVM/line_based_coverage_3: review: https://github.com/MoarVM/MoarVM/commit/641b736f94
11:03 dalek MoarVM/line_based_coverage_3: c5b9ae3 | lizmat++ | tools/parse_coverage_report.p6:
11:03 dalek MoarVM/line_based_coverage_3: Merge pull request #381 from MasterDuke17/line_based_coverage_3
11:03 dalek MoarVM/line_based_coverage_3:
11:03 dalek MoarVM/line_based_coverage_3: Give percentage its own column and add some JS+CSS to make the table sortable
11:03 dalek MoarVM/line_based_coverage_3: review: https://github.com/MoarVM/MoarVM/commit/c5b9ae3621
11:32 brrt joined #moarvm
11:33 brrt good * #moarvm
11:33 brrt one more question, and then i'm done
11:34 brrt how long do the live range objects themselves need to live?
11:34 brrt a): for the whole of the allocation scheme
11:34 brrt b): just as long as my cursor is within their range
11:35 brrt i.e. after spilling a live range, do i need to keep the descriptor arround
11:36 brrt if i do a): then splitting the register allocation from register assignment is somewhat simpler
11:37 brrt however, that may not really be a worthwhile goal anyway, because precoloring (assigning values to the place they are needed) needs to be coupled to register assignment anyway
12:02 vendethiel joined #moarvm
13:06 brrt joined #moarvm
13:45 timotimo brrt: i wish i knew the/an answer
14:08 brrt well, no reason to despair :-)
14:09 brrt the safe answer is just to keep them arround
14:09 timotimo i'd like to take a few more baby steps toward building the deopt bridges
14:14 brrt luajit, of course, only generates them on demand
14:20 timotimo you mean the bridges?
14:22 brrt well, they call them side traces
14:22 brrt but yes
14:22 brrt anyway, what's keeping you from starting with a few baby steps :-0
14:22 brrt :-)
14:23 timotimo dunno :\
14:24 timotimo i'll be duplicating the guard instructions with versions that take a BB
14:24 timotimo there's so many of them :|
14:24 timotimo and i don't really know which are most common(ly hit)
14:26 brrt why not start with just one
14:26 timotimo right. i probably should
14:26 timotimo make a suggestion? :)
14:29 brrt the simplest one... sp_guardtype or sp_guardconc
14:30 timotimo if i'm not mistaken, i need an op for each kind of deopt we can do, right? to put at the end of the bridge?
14:31 timotimo but i'll know at spesh time which one i need to emit because there's the deopt annotations in the code belonging to the guard
14:32 * timotimo puts a speshlog in front of him
14:33 timotimo 359 sp_guardconc
14:33 timotimo 42 sp_guardtype
14:33 timotimo 34 sp_guardrwconc
14:33 timotimo now if only i knew which one gets hit more often ...
14:36 timotimo now for some debugspam :)
14:37 brrt hmmmm
14:37 timotimo 701148 guardrwconc b0rked
14:37 timotimo 1273 guardtype b0rked
14:37 timotimo 727 guardconc b0rked
14:37 brrt it depends on how you want to do it
14:37 timotimo would you have guessed?
14:38 brrt no, wouldn't
14:38 timotimo wait a minute
14:38 timotimo i actually want to build bridges for the least often taken paths
14:38 timotimo because every bridge i build moves unnecessary code out of the mainline
14:39 timotimo if i were to immediately build a second speshed version based on "this guard didn't hold. but let's assume all other guards still hold", *then* i'd want to take the most often taken guards
14:41 timotimo that's going to happen in the future, but i have no clue how hard that'll be
14:41 timotimo i think i'd have to do a full re-spesh of the original code and turn the guard into a regular branch that'll take execution into a "parallel universe" where i'll clone most of the BBs
14:41 brrt hmmmmm
14:42 brrt ok, i may be naive, but....
14:42 timotimo that sound like i'd be re-speshing fully every time i detect hotness on a new guard, and i'd be doing that parallel-world-clone quadratically
14:43 brrt i was under the impression that the goal was to take a basic block that had some move operations; prove that these moves or copies are unnecesssary after a guard; move the copies to a new basic block, and have the guard point to that bb?
14:43 brrt so... why not do the proving thing first?
14:45 timotimo yes, that's the first milestone in this project
14:45 timotimo i'm getting far ahead of myself
14:48 * brrt knows what that is like :-)
14:48 timotimo :D
14:49 timotimo there's another thing i'd really like to get into moar, but i don't know how to properly engineer it
14:49 timotimo sometimes we build guards based on logs where the logs "figured out" some property that we already knew based on our regular fact discovery mechanism
14:50 timotimo so we'll end up with something like a create op followed shortly by a guard
14:50 timotimo i don't remember where i saw that example
14:50 timotimo for some reason i couldn't just check for the flags at the point where the log guard tries to set up its facts, because the flags were just 0 ... or something like that?
14:52 brrt hmmm
14:53 brrt i don't really know, to be honest
14:54 timotimo right, i'd have to find the example again
15:05 timotimo i'm really not sure i want to be messing around with the deopt table :|
15:06 brrt no.. i'm not suggesting that you should
15:06 brrt in fact, i'm not suggesting anything
15:06 timotimo oh, is it enough to just add a little annotation?
15:06 brrt i have no idea to be honest
15:07 timotimo in fact, i can just duplicate the annotation that's in front of the guard op?
15:12 timotimo it seems like i'll just be able to rip out the annotation that belonged to the sp_guard* and put it in front of my sp_forcedeopt
15:12 timotimo so at least that part is kind of figured out
15:13 timotimo and Deopt All apparently only appears before invoke_* ops
15:35 timotimo AFK for a bit
15:41 domidumont joined #moarvm
16:12 timotimo i think first i shall just turn sp_guardconc into sp_bridgeconc and immediately sp_forcedeopt
16:12 timotimo and see if anything breaks
16:16 domidumont joined #moarvm
16:17 timotimo oh crap
16:17 timotimo i'm adding branches to the *middle* of BBs
16:17 timotimo that sucks.
16:20 timotimo hm. i can potentially insert the new BB into the linear order and make it less crappy that way
16:20 timotimo otherwise there'd be a crazy amount of jumps back and forth?
16:40 zakharyas joined #moarvm
17:05 dalek joined #moarvm
17:05 synopsebot6 joined #moarvm
17:31 vendethiel joined #moarvm
17:51 domidumont joined #moarvm
17:51 brrt you'll have to split the basic block, that's for sure
17:51 brrt i can't really say what the fallout of tha tis
17:53 timotimo hopefully nothing
17:53 timotimo if i make sure the linear order stays correct?
17:54 timotimo and inside the bridges we won't be throwing exceptions or anything
17:56 brrt hmmm
17:56 brrt that is .... okay, but very, very, very fragile
17:58 timotimo oh?
18:03 timotimo could you elaborate?
18:19 brrt sorry, i'm somewhat busy
18:20 brrt i can see how it makes sense to keep the linear order, so that you don't upset the inlining and deoptimization tables
18:20 brrt on the other hand, that means you have to do that, forever
18:21 brrt the alternative is that your forcedeopt gets a fixed number that ... for all i care, represents the original position of your guard
18:22 timotimo forever %)
18:22 timotimo that is just fixed by stealing the annotation
18:22 timotimo easy-peasy
18:22 timotimo because the annotation has the data in it, as far as i can tell
18:23 brrt no upsetting of tables at all; it's outside of the range of the true code, but who cares
18:23 brrt because after the bridge, you're going back to the original code anyway
18:25 timotimo i only meant having the split put the two pieces a BB is split into in the original order
18:26 timotimo the bridge ought to go outside, of course. especially when we expect it to not be taken often
18:27 brrt ah, alright
18:27 brrt right, fully agree
18:29 timotimo so, no worries about fragility? or doing something "forever"?
18:38 domidumont joined #moarvm
18:43 brrt no, not really
18:43 brrt in fact, the reverse
18:43 brrt safe splitting of basic blocks is something we will probably need a lot of time
19:29 FROGGS joined #moarvm
21:10 timotimo hm. vim over sshfs isn't working very well with all those modules i have, it seems like
21:11 Util joined #moarvm
21:13 timotimo waiting multiple minutes to open this file ... ?!?
21:14 hoelzro o_O
21:18 psch ...use ed?
21:19 timotimo nah, i'm using vim inside ssh now
21:23 timotimo ugh. idx. not fun :|
21:23 timotimo for splitting BBs, i mean. i'll have to come up with a new index
21:24 timotimo well, i can just go through linear_next and +1 the idxes
21:24 timotimo they aren't supposed to be stable anyway
21:24 timotimo ugh, initial_pc is supposed to just be the cached instruction pointer at the beginning
21:25 timotimo and it's an uint, so i can't just set it to -1
21:26 timotimo i think i can just re-use the initial_pc from the original BB when i split
21:30 vendethiel joined #moarvm
21:41 timotimo this is an ugly task
22:30 dalek MoarVM: bdff4dc | timotimo++ | src/spesh/manipulate. (2 files):
22:30 dalek MoarVM: Implement a BB-splitting manipulation function
22:30 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/bdff4dc9e3
22:30 timotimo ^- i bet it's b0rked beyond belief :)
22:46 timotimo i'd be pretty glad if someone would commet and/or fix ;)
22:46 timotimo a bit drained today, so not going to put in the "split basically everywhere" thing
22:50 travis-ci joined #moarvm
22:50 travis-ci MoarVM build failed. Timo Paulssen 'Implement a BB-splitting manipulation function'
22:50 travis-ci https://travis-ci.org/MoarVM/MoarVM/builds/142899784 https://github.com/MoarVM/MoarVM/compare/8fc21d50aa4f...bdff4dc9e3a3
22:50 travis-ci left #moarvm
22:56 timotimo well, i should have at least tried to build it, seems like
22:58 dalek MoarVM: f9dad06 | timotimo++ | src/spesh/manipulate. (2 files):
22:58 dalek MoarVM: fix signature of split_BB_at
22:58 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/f9dad06052
23:24 travis-ci joined #moarvm
23:24 travis-ci MoarVM build passed. Timo Paulssen 'fix signature of split_BB_at'
23:24 travis-ci https://travis-ci.org/MoarVM/MoarVM/builds/142905385 https://github.com/MoarVM/MoarVM/compare/bdff4dc9e3a3...f9dad06052ff
23:24 travis-ci left #moarvm
23:25 timotimo good

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