Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2014-07-05

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

All times shown according to UTC.

Time Nick Message
01:50 FROGGS_ joined #moarvm
03:56 btyler joined #moarvm
07:40 ingy joined #moarvm
08:20 FROGGS[mobile] joined #moarvm
08:53 brrt joined #moarvm
09:09 brrt \o #moarvm
09:42 jnthn o/ brrt, #moarvm
09:42 brrt how's today
09:43 jnthn fine so far
09:43 jnthn not raining, have coffee... :)
09:44 jnthn How about for you?
09:47 brrt hot, hot, hot
09:48 brrt but as it stands rain should come in about 6 hours
09:48 masak \o/
09:49 brrt hmm...
09:49 brrt i think i can do sp_fastinvoke, that should be doable
09:50 brrt but i'm off for lunch now :-) bbiab
09:52 jnthn k :)
10:43 dalek MoarVM: a4cdc2d | jnthn++ | src/spesh/inline.c:
10:43 dalek MoarVM: Fix merging of inline table entries.
10:43 dalek MoarVM:
10:43 dalek MoarVM: Need to add offsets to return address deopt location, locals, and
10:43 dalek MoarVM: lexicals.
10:43 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/a4cdc2d8aa
10:43 dalek MoarVM: b0df62c | jnthn++ | src/spesh/deopt.c:
10:43 dalek MoarVM: Improve deopt debug fprintfs.
10:43 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/b0df62c142
10:55 brrt joined #moarvm
10:57 * brrt predicts that b0df62c1 will cause merge annoyance later on
10:57 jnthn Sorry
10:57 brrt np :-)
10:57 jnthn At least it's only commented out code ;)
10:58 jnthn That fixes the nasty deopt bug typevaropt was blocking on, though, it seems.
10:58 * tadzik attempts cross-compiling nqp for ARM again
10:58 tadzik it's slooooow
10:58 brrt it's no problem, of course - i change the segments without merging them back, shouldn't be surprised if stuff breaks in the meantime
10:58 tadzik but probably still faster than doing it on device :)
10:58 brrt oh? good time for me to merge-update?
10:59 jnthn Maybe...
10:59 * jnthn is just doing a spectest.
11:01 jnthn yeah, that cleans up the issues
11:02 jnthn So, probably a good time.
11:02 brrt ok, i'll update then
11:02 brrt :-)
11:04 jnthn Warning: you'll be dragging in OSR too :)
11:06 brrt i think i've done that already
11:06 brrt and it doesn't seem to have caused any troubles, probably because i haven't been able to JIT OSR-frames yet :-)
11:09 jnthn ah, ok :)
11:11 dalek MoarVM/moar-jit: 6b458f7 | (Tobias Leich)++ | src/6model/reprs/CPointer.c:
11:11 dalek MoarVM/moar-jit: allow pointer math using CPointer repr
11:11 dalek MoarVM/moar-jit:
11:11 dalek MoarVM/moar-jit: This means that NativeCall's OpaquePointer type can be gistified as
11:11 dalek MoarVM/moar-jit: OpaquePointer<0x7f9e8db8fda0>, which will be helpful for debugging
11:11 * brrt facepalm
11:12 dalek joined #moarvm
11:12 brrt i thought dalek recognised merges?
11:12 jnthn Only if you merge enough commits.
11:13 jnthn It goes on a "how many" heuristic, rather than looking at the topology
11:14 * jnthn thinks of the world cup logo every time he hears "facepalm" :)
11:14 brrt lol
11:15 brrt i don't have good hopes for belgium tonight
11:17 jnthn Playing a South American team in South America is quite a big ask...
11:19 brrt netherlands will be up against costa rica, and i'm actually expecting they'll win
11:19 jnthn Yes, I'd hope so.
11:20 brrt i'm neutral towards it, but i expect it :-)
11:21 jnthn Well, we know at least one European team is into the semis, but one or two more would be nice :)
11:22 brrt then if one of {netherlands, belgium} wins tonight, it'll be nicely balanced
11:23 jnthn aye
11:24 jnthn If both win, it'll be an entertaining semi :)
11:25 brrt indeed
11:25 jnthn Bring teams from all over the world, and the semi-final ends up being two that are right next to each other :)
11:25 brrt that's what i'm kind of hoping for
11:26 jnthn Even funnier if Germany manage to beat Brazil and final is something like Netherlands vs Germany, or Belgium vs Germany. But beating Brazil on home turf will take quite something...
11:27 brrt i'd be very surprised if that happened
11:29 brrt can you remind me to blog today?
11:29 jnthn brrt: Blog today.
11:29 jnthn Though I guess you meant, later on today :)
11:29 brrt :-) and i'd also like your input on the following problem i'm having, or challenge, or call it what you will
11:29 brrt later on perhaps
11:30 brrt :-)
11:30 jnthn k
11:30 brrt basically, i have a number of 'system variables' - like the current frame, the compilation unit, the input args buffer, the out args buffer, etc
11:31 brrt and i'd like to keep these in the callee-save registers, but i don't quite have enough of those do keep all of them, and moreover, it's wasteful to do so
11:32 brrt what i do now is keep some of them at all times - threadcontext, compunit, work registers, inargs registers
11:32 brrt and get all others on a temporary basis
11:33 brrt but what i'd like to do is to have 'sections' of the jit graph where one set of system variables would be in certain frames, and at other times, other segments
11:34 brrt i.e. i don't typically need to keep inargs in a special register for very long because - most of the time - all argument reading happens in the first basic block or so
11:34 jnthn Right.
11:36 jnthn Though there's no easy way to know where args reading ends
11:37 jnthn And calls could happen in the middle of it.
11:37 jnthn (sub foo($x = blah(), :$y) { }; foo(y => 'bear'))
11:38 brrt basically my idea was to have ops that require, e.g. the current frame, to 'ask' the jit graph to load the current frame, and have the compiler only emit loads at 'borders'
11:38 brrt hmm i see
11:38 brrt that's ok, still
11:38 brrt that's why we have callee-save registes, after all :-)
11:40 jnthn true :)
11:42 brrt hmm... if that were the only 'codegen optimisation' i'd get done this summer, i'd still be (somewhat) happy, but not as happy as i could be
11:43 jnthn Well, I still see it as somewhat secondary to being able to JIT e.g. calls. :)
11:44 brrt agreed
11:44 brrt but i'm getting to that right now :-)
11:45 jnthn True :-)
11:45 jnthn It'll be rather nice when some of the benchmarks from perl6-bench can benefit :)
11:47 brrt i don't suppose we have the code target of sp_fastinvoke at spesh time, or do we?
11:48 jnthn The point of sp_faskinvoke is it knows exactly where it's going
11:48 brrt hmm
11:48 jnthn "we know enough to inline it, but it doesn't make sense or contains things that make inlining impossible"
11:48 jnthn So we know the code target *and* the spesh candidate
11:49 brrt hmmm
11:50 jnthn (Meaning you may also statically know it's jitted :))
11:52 brrt yes, i suppose so; but this doesn't seem to directly repesented in the spesh graph
11:56 jnthn The info is there, 'cus that's how the optimizer knows it can use sp_fastinvoke
11:57 * brrt looks at it
11:57 jnthn It should just be that the register holding the invokee has a facts table entry with the code as the object value.
11:58 jnthn iirc there's a get facts function that takes a MVMSpeshOperand
11:59 brrt oh, that is actually quite likely; that'd be a good reason for sp_getspeshslot
12:00 jnthn Yeah, or you can just grab the spesh slot index. :)
12:00 jnthn and look it up that way
12:00 jnthn tmtowtdi :)
12:01 brrt :-) fortunately
12:16 jnthn Time to go shopping. bbiab.
12:24 brrt needs to be done, too
12:33 FROGGS_ joined #moarvm
12:34 * brrt seems to need greater amounts of caffeine today
12:47 * [Coke] grrzzzcoffeee
12:48 brrt i only have tea right now, that might be the cause of it
13:08 brrt bbiab
13:08 brrt left #moarvm
13:39 carlin joined #moarvm
14:34 brrt joined #moarvm
14:45 brrt \o #moarvm
14:46 timotimo o/
14:50 jnthn wb, brrt
14:50 timotimo wbrrt
14:51 brrt lol
14:55 tgt joined #moarvm
14:58 dalek MoarVM: 84abb89 | jnthn++ | src/spesh/ (4 files):
14:58 dalek MoarVM: Rename to ensure it's clear guards relate to args.
14:58 dalek MoarVM:
14:58 dalek MoarVM: This will contrast them with log-based guards.
14:58 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/84abb89d1f
15:05 brrt hmmm
15:06 brrt it occurs to me that storing the 'jit return address' in the current frame is only possible when that frame is still... current
15:08 jnthn "current"?
15:08 brrt i.e. when i call MVM_frame_invoke and that updates the whole threadcontext, and cur_frame is changed to point to the callee frame, it is basically too late - or at least inelegant - to set the return address then
15:09 brrt it will cause ugly bugs, is what i'm saying, i guess :-)
15:09 brrt (because: what happens with tails calls?)
15:09 timotimo do we do tail call optimization in the jit? :)
15:10 jnthn MoarVM's execution strategy is an entire tail call optimization if you squint... :)
15:10 jnthn We don't recurse on the C stack.
15:10 jnthn brrt: Well, the invoke instructions stash the return address *before* calling MVM_frame_invoke.
15:11 brrt that is only true in a very limited sense :-) we do recurse on the MVMFrame stack
15:11 timotimo haha, right
15:11 jnthn Oh, sure. But not the C stack. Which is really important for not introducing continuation barriers.
15:11 timotimo but we do have frames that get allocated on a stack-like structure
15:11 jnthn Yeah. More a DAG than a stack, but yes :)
15:11 timotimo i generally know TCO as "not even allocate a new frame when recurring"
15:12 jnthn Well, Idid say you have to squint :P
15:12 timotimo and look the other way as well? :)
15:12 * brrt wonders about the DAG-like nature of the frame graph
15:12 dalek MoarVM: ab8eb2d | jnthn++ | src/ (5 files):
15:12 dalek MoarVM: Keep a table of added log-based guards.
15:12 dalek MoarVM:
15:12 dalek MoarVM: Not updated with usages or used for anything yet; just initialized.
15:12 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/ab8eb2deb8
15:12 jnthn brrt: Well, there's two relationships: caller and outer.
15:12 timotimo ah, removal of unnecessary log guards
15:12 timotimo very good
15:13 jnthn timotimo: Well, that's what I'm preparing for, yes.
15:13 timotimo yup
15:13 timotimo i seem to recall you said deopt is kinda cheap?
15:13 timotimo i mean the jump itself
15:14 timotimo not running the spesh'd bytecode any more, even though we could, would probably be the bigger deal
15:15 brrt anyway.... my point is, i'd want to set the return address /before/ calling mvm_frame_invoke too, but that means the strategy of returning a label number to the 'driver' to set the continuation becomes an inelegant strategy, that also relies on the jit-frame also being the caller frame, and that might not hold if - for example - we could decide we didn't need the jit frame after the call anymore (i.e. TCO)
15:15 jnthn It's kinda cheap, but doing it when you're in an inlined thing has to go allocating frames and reconstructing the outer chain...
15:16 brrt outer is based on staticframe's in some way, right?
15:16 jnthn uh, caller chain...
15:16 jnthn No, outer is from statically knowing the code object.
15:16 timotimo of course
15:16 jnthn Which by definition you do if you've inlined stuff.
15:16 timotimo do you have a clue how often we deopt inlined things vs just speshed things in general?
15:17 jnthn Didn't do any measruements, but I know it can happen quite a lot.
15:17 jnthn And typically in places it needn't.
15:17 timotimo OK
15:26 brrt ok, i'm almost ready with my blog post, but at any rate, the gist of it is that i decided to do the following
15:29 brrt a): mvm_jit_enter returns an integer which is nonzero if the frame has 'run its course', i.e. is at it's natural end, in which case b): the driver should call mvm_frame_try_return, because it'll have to know if it should exit the loop, and this way each of the code seems to have its own responsiblity
15:30 brrt c): the jitted code will have to set its return address /before/ calling MVM_frame_invoke, and d): possibly just return 1 when done, zero when not 'done' (which can be directly returned to the interpreter
15:30 brrt but, bbiab :-)
15:31 jnthn :)
15:45 zakharyas joined #moarvm
15:45 timotimo i was a bit worried when i read the return value would either be a pointer to jump to or a negative value; aren't pointers unsigned?
15:50 dalek MoarVM: 80ab0b4 | jnthn++ | src/spesh/facts.c:
15:50 dalek MoarVM: Copy log guard when computing dependent facts.
15:50 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/80ab0b4243
15:53 dalek MoarVM: 8131c29 | jnthn++ | src/spesh/optimize.c:
15:53 dalek MoarVM: Add simple guard use analysis
15:53 dalek MoarVM:
15:53 dalek MoarVM: Not perfect, but an over-approximation, to start with: if we ever ask
15:53 dalek MoarVM: for the fact, then consider it used.
15:53 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/8131c290d0
16:02 dalek MoarVM: 708dd7d | jnthn++ | src/spesh/optimize.c:
16:02 dalek MoarVM: Remember to copy log_guard with facts.
16:02 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/708dd7d179
16:02 dalek MoarVM: 9357879 | jnthn++ | src/spesh/optimize.c:
16:02 dalek MoarVM: Eliminate unused guards.
16:02 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/9357879784
16:21 vendethiel joined #moarvm
16:29 btyler joined #moarvm
16:40 FROGGS_ jnthn: &foo:(Int,Num) is about selecting an already existing MMD candidate
16:41 FROGGS_ we'd need something nice to declare a callable attribute of a CStructish class, and, be able to cast a pointer to something callable
16:46 jnthn std: class A { has &.x:(Int, Str --> Num); } # curious
16:46 camelia std 0f2049c: OUTPUT«ok 00:01 131m␤»
16:51 japhb_ o/  # Back from offline vacation  :-)
16:51 jnthn Hope it was a nice vacation :)
16:51 japhb_ It was indeed.
16:53 japhb_ Started looking at Rat/FatRat benchmarks for you, jnthn.  I'm noticing that perl5's Math::BigRat is S-L-O-W.  Like seriously-that-can't-be-right slow, in the case of my Harmonic Series test.
16:53 jnthn Wow
16:53 jnthn So slow that we beat it? :)
16:54 japhb_ Easily, when I was futzing at the command line.  I haven't run 'em through perl6-bench yet, though; I was just refining the scriptlets I was going to use.
16:54 jnthn *nod*
17:01 FROGGS_ std: class A { has &.x:(Int, Str) returns Num; }
17:01 camelia std 0f2049c: OUTPUT«ok 00:01 130m␤»
17:02 FROGGS_ std: class A { has &.x:(Int, Str) returns Num is native('foo'); }
17:02 camelia std 0f2049c: OUTPUT«ok 00:01 133m␤»
17:03 FROGGS_ I'm not sure it is meant to be doing what we want though
18:31 zakharyas joined #moarvm
19:34 dalek MoarVM/nativecast: 2b68449 | (Tobias Leich)++ | src/core/nativecall.c:
19:34 dalek MoarVM/nativecast: fix bogus declaration (copy&pasto)
19:34 dalek MoarVM/nativecast: review: https://github.com/MoarVM/MoarVM/commit/2b68449748
19:47 carlin joined #moarvm
19:49 carlin joined #moarvm
19:58 brrt joined #moarvm
19:59 vendethiel joined #moarvm
20:10 vendethiel joined #moarvm
22:12 carlin joined #moarvm

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