Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2015-07-14

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

All times shown according to UTC.

Time Nick Message
01:25 vendethiel joined #moarvm
02:00 colomon joined #moarvm
03:26 colomon joined #moarvm
03:45 lizmat joined #moarvm
04:10 TEttinger joined #moarvm
04:25 vendethiel joined #moarvm
05:57 vendethiel joined #moarvm
06:17 FROGGS joined #moarvm
06:47 zakharyas joined #moarvm
07:10 vendethiel joined #moarvm
07:38 FROGGS joined #moarvm
07:39 vendethiel joined #moarvm
08:09 vendethiel joined #moarvm
08:36 vendethiel joined #moarvm
09:33 vendethiel joined #moarvm
10:56 Ven joined #moarvm
11:24 brrt joined #moarvm
11:31 brrt it occurs to me that it would be correct to a): spill fully at every 'spillish' IR op, (call/if/when)
11:32 brrt b): dump all registers allocated within each conditional 'block'
11:43 brrt .... or, put in other words, a expression tree is bigger than a basic block
11:55 colomon joined #moarvm
12:00 brrt if we're looking at the minimum spill extent, then i'd note that they 'bubble up'
12:01 brrt a single fully-destructive spill deep in a branch somewhere - i'm looking at write-barriers in particular - destroys all registers all the way up to the highest branch
12:02 brrt this, in other words, sucks
12:03 brrt but the question 'what to spill' is largely independent from 'where to spilli t'
12:03 brrt it
12:03 brrt and is also indpendent of the question 'to which location'
12:05 brrt so properly considered, there are three questions
12:05 brrt a): where is it necessary to spill registers
12:05 brrt b): which registers are necessary to spill
12:06 brrt c): where should we spill the registers to
12:07 brrt c can be solved by figuring out where a certain node stands for
12:08 brrt i.e. if it does or does not stand for a local
12:12 brrt a local value can always be spilled to it's local register, a temporary value needs to be spilled to stack space
12:26 brrt joined #moarvm
12:28 jnthn brrt: Why are write-barriers fully destructive, ooc? 'cus they involve a call?
12:30 brrt aye
12:30 brrt annoyingly, only a branched call, and not necessarily a likely one at that
12:30 brrt but i... hmmm
12:30 brrt oh
12:30 brrt of course, i can also compile 'restoration' code post-call
12:31 brrt within the branched segment, that is
12:32 brrt e.g if foo: spill; call; restore; end rather than spill; if foo; call; end; restore
12:32 brrt is that much more complex? hmmm.... yes-ish, but not that much
12:35 brrt as in, it doesn't require any knowledge that any of the other spilling schemes don't also require
12:40 brrt i can, of course, spill completely defensively
12:40 brrt as in, spill all values upon an if or call
12:40 brrt spilling is easily the hardest problem i've seen so far :-)
12:47 jnthn Well, there's always the option of doing the simple/obviously correct thing first, and then the cleverer thing once that's working
12:49 brrt that is true
13:00 brrt the simple/obvious thing would be to emit a spill before a branch, after a branch, and before a call
13:01 brrt noting that i don't want to do loops within the expression tree themselves
13:01 brrt that would go so far from the notion of a loop as to be pointless :-)
13:03 brrt s/loop/tree/
13:11 LLamaRider joined #moarvm
13:13 oetiker joined #moarvm
13:19 brrt i think my theory of a generic traverser was quite wrong
13:20 colomon joined #moarvm
13:21 brrt or... not
13:22 brrt hmm
13:23 FROGGS jnthn: I can do that return_* stuff only from within that frame, right?
13:24 FROGGS ahh, nvm, perhaps
13:32 jnthn FROGGS: Right
13:32 jnthn FROGGS: We could set up a leave handler around the whole block maybe
13:32 jnthn That does a getpayload/return_o
13:33 jnthn Then as we unwind towards the block we'll run all the needed LEAVE phasers
13:34 brrt yay JIT news :-)
13:35 FROGGS where would we add the leave handler? when handling the exception?
13:35 brrt http://v8project.blogspot.nl/2015/07/digging-into-turbofan-jit.html
13:35 brrt looks *suspiciously* like SSA
13:37 JimmyZ__ joined #moarvm
13:40 jnthn FROGGS: Well, I was thinking it's just a normal entry in the exception handler table...or is thatnot what you meant?
13:40 jnthn Actually I don't understand the question... :)
13:41 jnthn Do you mean "does the QAST->MAST emit it for every block"?
13:41 jnthn I don't know that can work 'cus we need a chance to enforce type checks
13:41 jnthn In fact, for routines we'd really like return and leave to hit the same handler... Hm.
13:41 jnthn We also have this bug:
13:42 jnthn m: sub foo($x = return 42) { }; say foo()
13:42 camelia rakudo-moar 533d1a: ( no output )
13:42 jnthn I've no idea what that actually returns from. But I think we can agree it's bust...
13:43 jnthn I think we may need a different factoring for attaching the return/leave handlers anyways.
13:53 FROGGS I don't get why I don't find the code_ref of the block...
13:53 jnthn Me either...
13:53 jnthn It's still on le call stack, yes?
13:54 FROGGS yes, I think so
13:54 FROGGS I have: do { &?BLOCK.leave }
13:55 jnthn Can you try it with --optimize=off (to Perl 6)?
13:56 FROGGS no luck
13:56 jnthn Hm, that's one hypothesis out then
14:02 FROGGS hmpf, we also do not care about labels attached to blocks yet
14:05 FROGGS does normal blocks have frame handlers?
14:06 jnthn Any MoarVM code block can have them
14:07 jnthn uh, frame
14:08 FROGGS okay, we do not attach the labels to these atm...
14:14 vendethiel joined #moarvm
14:39 vendethiel joined #moarvm
14:41 brrt bbiab
15:02 zakharyas joined #moarvm
15:29 brrt joined #moarvm
16:15 dalek joined #moarvm
18:22 nebuchad` joined #moarvm
18:25 hoelzro_ joined #moarvm
18:25 btyler_ joined #moarvm
18:32 dalek joined #moarvm
18:57 tadzik joined #moarvm
19:08 flussence joined #moarvm
19:09 flussence joined #moarvm
19:11 flussence joined #moarvm
19:39 _longines joined #moarvm
19:49 ggoebel joined #moarvm
19:52 timotimo joined #moarvm
19:52 retupmoca joined #moarvm
19:52 hoelzro_trying_w joined #moarvm
20:10 zakharyas joined #moarvm
20:38 nwc10 A new blog post: http://blog.pyston.org/2015/07/14/caching-object-code/
20:39 nwc10 previous was on 2015/02/24
20:50 TEttinger joined #moarvm
20:53 jnthn "we JIT 66 python functions which takes about 1.4secs"
20:54 jnthn That cost surprises me a little.
20:59 jnthn Caching JITted code is a nice idea, though. Maybe we can borrow that some day. But yeah, it needs care.
20:59 jnthn I wonder where they keep the cache, and if there are any security worries. I think not because of the hashing they do
21:20 cognominal what is the purpose of nqp::markcodestatic?
21:21 cognominal I want to document some nqp:: ops about coderef, but this one I can't figure out (yet)
21:21 cognominal it seems related to serialization
21:25 [Coke] cognominal: in docs/ops.markdown ?
21:26 cognominal I want to document ops missing fromm ops.markdown :)
21:28 cognominal hopefully, nqp/t/03-closures.t seems helpful as example
21:31 [Coke] right, just making sure that's where the docs are going. awesome, thanks!
21:32 jnthn cognominal: It's about identifying the "original" code object from any closure clones of it.
21:32 cognominal Also p6 ops are undocumented to.
21:32 jnthn And yes, we care for serialization purposes.
21:33 cognominal ok, that makes sense.
21:33 cognominal jnthn++
22:08 flussence joined #moarvm
23:02 Ven joined #moarvm
23:49 cognominal joined #moarvm

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