Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2014-06-14

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

All times shown according to UTC.

Time Nick Message
00:17 cognominal__ joined #moarvm
01:32 FROGGS joined #moarvm
01:54 FROGGS joined #moarvm
05:17 cognominal__ joined #moarvm
05:17 cognominal__ joined #moarvm
06:39 lizmat joined #moarvm
07:14 brrt joined #moarvm
07:15 brrt .tell jnthn if he could, would he care to test moar-jit on win64
07:15 brrt i /think/ i've implememted the abi correctly
07:15 brrt but how can you tell? :-)
08:02 lizmat joined #moarvm
08:03 woolfy joined #moarvm
08:09 brrt is MVMArgProcContext * args different from MVMFrame -> args
08:09 brrt ?
08:11 * brrt is already figuring it out
08:12 brrt its different
08:12 brrt ok, good to know
08:18 lizmat joined #moarvm
09:37 brrt joined #moarvm
12:08 cognominal joined #moarvm
12:27 jnthn .tell brrt it appears the JIT works out nicely on win64 \o/
12:30 brrt joined #moarvm
12:32 lizmat jnthn: so what was jitted (so I can mention in my talk in 15 mins)
12:32 timotimo something like "1 + 3"
12:32 brrt lizmat: the routine 2 + 2 = 4
12:33 timotimo er, that's not legit code :)
12:33 brrt fair enough
12:33 brrt return 2 + 2;
12:33 lizmat so beyond constant folding ?
12:33 brrt and apparantly it works on win64 :-D
12:34 timotimo there's also a "say "OH HAI"" in foo.nqp, does that get jitted, too?
12:34 jnthn lizmat: The takeaway isn't so much "we can JIT 2 + 2" as "we have all the infrastructure in place to JIT stuff, and have a first trivial example working" :)
12:34 brrt just that, yes
12:34 timotimo does it get jitted into a machine-code add instruction or into an invocation of moarvm's "add two integers" function?
12:34 lizmat so this would be an adequate description: "First JITted code execution already seen!"
12:34 brrt i think so, yes
12:35 brrt timotimo - into an add instruction, yes
12:35 timotimo sounds good :)
12:36 brrt oh, i should've sent the 'bytecode with explanation' on my blog, too
12:36 timotimo aye
12:38 timotimo brrt: would a wild sub test() { 2 + 2 } become jitted, too? or does that contain some tricky ops you can't do yet?
12:38 brrt that contains checkarity, iirc
12:39 timotimo ah, could be.
12:39 brrt and... i haven't checked that out really
12:39 timotimo well, after it's spesh'd, it shouldn't have checkarity any more
12:39 timotimo and jit comes after spesh, no?
12:40 brrt yes
12:40 brrt well, try it out, i'd say :-)
12:40 timotimo could do :3
12:43 jnthn After it's spesh'd, the checkarity is gone. :)
12:45 jnthn yeah, it spesh's to just:
12:45 jnthn const_i64_16 r0(1), liti16(2)
12:45 jnthn const_i64_16 r1(1), liti16(2)
12:45 jnthn add_i r1(2), r0(1), r1(1)
12:45 jnthn return_i r1(2)
12:45 brrt actuall, it does
12:45 jnthn :)
12:45 brrt so
12:45 TimToady so after spesh the intermediate language is SpeshIL?  :)
12:45 brrt timotimo - the answer is yes
12:45 timotimo \o/
12:46 timotimo TimToady: *groan* :)
12:46 jnthn :P
12:47 timotimo except if you have code like sub a() { 2 +2 }, the optimizer will turn it into sub a() { 4 } already :)
12:47 timotimo the jit doesn't do "get arguments" yet, right? not even the spesh'd variants?
12:47 brrt it doesn't on moar-jit, not yet
12:48 timotimo right; should be simple to do, once it bubbles to the top of your todo list
12:48 jnthn timotimo: The NQP optimizer doesn't yet.
12:48 brrt well, i think it should be done on the spesh level tbh
12:49 timotimo oh!
12:49 timotimo brrt: what exactly?
12:49 brrt constant folding
12:49 timotimo ah, fair enough
12:50 brrt basically, i don't know (yet) if the registers that store the constants will be used another time
12:50 brrt in theory that is possible (although unlikely)
12:50 timotimo i'm getting "emit" debug output from my sub a() { 2 + 2 } example in nqp \o/
12:50 jnthn brrt: Now something basic is working, what's your plan from here?
12:50 timotimo https://gist.github.com/timo/e435363b9ecc25bb9495
12:51 brrt uhm, i'd point you to my recent blog entry :-) but in short
12:51 brrt timotimo : thats what i get too :-)
12:51 jnthn oh, did I miss a post/ :)
12:51 brrt o it hasn't bubbled through yet
12:51 jnthn why yes, I did...
12:51 brrt i've just written it this morning
12:51 jnthn I see it now :)
12:51 timotimo oh!
12:51 brrt in short, - positional parameters
12:51 brrt - more arithmetic
12:52 brrt - branching and conditionals
12:52 brrt - phi node reduction
12:53 jnthn +1 to an MVM_JIT_LOG env var
12:53 timotimo how come branching seems like the hardest part?
12:53 brrt because it means linearizing the tree, in effect
12:53 jnthn I suggest that dumping the JIT tree could be a good idea.
12:54 brrt that, or it moves the block navigation down to the compiler
12:54 brrt i agree
12:54 jnthn I've got a lot out ot spesh_log being full of spesh dumps
12:54 brrt ok, that moves up, too, then :-)
12:54 jnthn The other thing you could do is have an env var where you give it a directory and it dumps the JIT compiled output for disasm-ing.
12:55 jnthn And name the files according to some identifier that ends up in the jit tree log, so it's possible to correlate the two.
12:56 jnthn I've found building small logging-ish things like this has been a huge time-saver overall, as it helped me debug all sorts with spesh.
12:56 brrt atomically incrementing integer? or do we still have the cu-uuid at spesh-graph time?
12:56 jnthn You can find the cuuid but we might specialize the same one multiple times.
12:57 brrt fair enough
12:57 jnthn brrt++ for the post
12:57 brrt i kind of want to move the staticframebody into the spesh graph
12:58 jnthn I suspect "set" will be an important, and easy, opcode.
12:58 brrt i've done set
12:58 jnthn ?
12:58 jnthn you already have g->sf
12:58 brrt or a pointer-to-the-staticframebody :-)
12:58 brrt i do?
12:58 brrt oh
12:58 brrt i said /nothing/ :-D
12:58 jnthn g->sf.body # gets you the body.
12:59 brrt ok, that will be awesome
12:59 brrt more reason for me, though, to push through with my next change
13:00 brrt create a 'copy' (or 'store', or 'load-and-store', or 'move') node
13:01 brrt why do that? because moving stuff back and forth is basically what i do all day, and creating a node has me move the decisions of what to move upward to graph creating
13:02 jnthn Sounds sensible.
13:04 dalek MoarVM/inline: ed2a763 | jnthn++ | src/core/ext.c:
13:04 dalek MoarVM/inline: Make sure extops don't leave noinline as junk.
13:04 dalek MoarVM/inline: review: https://github.com/MoarVM/MoarVM/commit/ed2a7632b5
13:04 brrt i noticed param_op_i isn't yet speshed to sp_getarg_i
13:04 jnthn It *may* be.
13:04 brrt hmmm
13:04 jnthn It depends on an arg_i being passed
13:05 jnthn At some point it should learn to spesh an object being passed into sp_getarg_o followed by unbox_i
13:05 dalek MoarVM/moar-jit: 5fff8c3 | (Bart Wiegmans)++ | / (5 files):
13:05 dalek MoarVM/moar-jit: Implement a few more opcodes.
13:05 dalek MoarVM/moar-jit: review: https://github.com/MoarVM/MoarVM/commit/5fff8c3598
13:05 jnthn Where unbox_i will be able to further spesh into sp_get_i I guess...
13:06 brrt i hope
13:06 brrt :-)
13:08 timotimo you forgot to add a label for set into the jit.c dispatch switch thingie, no?
13:09 jnthn brrt: About /* I basically don't really want to use the TC's CompUnit ...
13:10 jnthn You have the sf, and you can sf->body.cu to get to it safely.
13:10 brrt right :-) that was exactly my question
13:10 brrt i may have forgotten that timotimo
13:10 brrt :-)
13:10 timotimo as you can see, your mentors are following your commits closely ;)
13:11 jnthn It's almost like they care the project is successful :P
13:12 timotimo mentors work in mysterious ways
13:12 brrt :-D
13:12 timotimo jnthn: as soon as OSR + jit land, the benchmarks will look incredible for perl6-m (or at least nqp-m)
13:12 brrt on-stack-replacement?
13:13 timotimo yes
13:13 timotimo so that we can spesh single-layer for loops even if they don't invoke some sub inside
13:14 timotimo also i imagine inlining will cause less "entry points" for going from the regular bytecode to the spesh'd bytecode?
13:15 brrt i hope so
13:15 jnthn Yeah, well, I gotta get inlining in shape before any OSR :)
13:15 timotimo of course
13:16 timotimo why don't i see any jnthn commits? :P :P
13:16 timotimo .o( i should also be working, rather than complain that others aren't )
13:18 cognominal joined #moarvm
13:18 * TimToady is just a tor-mentor
13:18 jnthn hey, there was a fix for one of the inline valgrind failures just 15 mins ago :P
13:19 jnthn Or, I hope it's a fix for it :)
13:20 TimToady jnthn: are we planning to handle int -> Int overflow via spesh/deopt?
13:20 timotimo okay okay :)
13:21 timotimo TimToady: i didn't know we ever do int -> Int?
13:21 TimToady I mean Int -> int -> Int :)
13:21 timotimo i don't think we do that yet, either
13:21 TimToady spesh to int, deopt back to Int
13:21 TimToady well, maybe spesh to int64
13:22 timotimo would that be "strength reduction"? "boxing elimination"?
13:22 TimToady I just think of it as using native ints rather than Int objects :)
13:22 timotimo we already have a "fast path" both for data storage and for calculations that makes Int better if the values fit into 32 bit (on moarvm)
13:23 TimToady right, I forgot that
13:23 brrt the whole 64 bit mess is messy
13:23 timotimo not sure how we could make that better using knowledge gained from spesh
13:26 jnthn TimToady: I was more thinking initially to do those just by JITting the fast path and if it spots an overflow (or an input to the operation is already overflowed) then it falls back to the slower path instead.
13:26 timotimo jnthn: how easy is it to spot overflows in all the ops we support?
13:26 timotimo can we just tell the cpu to trap overflows and set some register or something?
13:26 jnthn Well, for the common ones that map to CPU operations, I *think* it's checking a flag.
13:27 timotimo in that case, branch prediction probably makes things cheap-ish if we're long-running
13:28 jnthn aye.
13:28 jnthn hmm, this read-past-end-of-buffer of the lexicals marking is a curiosity...
13:29 jnthn We always get the locals marked OK.
13:31 brrt yes, integer overflow is a flag iirc
13:33 * brrt afk
13:33 brrt left #moarvm
14:07 jnthn Yay, I think I have a fix for all thsoe buffer overruns when marking env.
14:07 lizmat jnthn++ # can't be said enough
14:10 dalek MoarVM/inline: 212b75d | jnthn++ | src/gc/roots.c:
14:10 dalek MoarVM/inline: Don't use spesh'd lexical map for logging frames.
14:10 dalek MoarVM/inline:
14:10 dalek MoarVM/inline: A frame may have a spesh_cand, but only because it was being used for
14:10 dalek MoarVM/inline: doing logging. The spesh cand will later be updated with a type map,
14:10 dalek MoarVM/inline: but the logging frames will not have had anything inlined, so won't
14:10 dalek MoarVM/inline: have allocated that much environment storage.
14:10 dalek MoarVM/inline: review: https://github.com/MoarVM/MoarVM/commit/212b75d7de
14:10 jnthn Managed to re-create the isssue by tracking allocation size, adding an extra check, then getting it to GC every 32KB allocated. :)
14:20 timotimo ouch, that sounds slow :)
14:21 jnthn Wasn't so bad.
14:21 jnthn :)
14:22 jnthn Next issue is why a couple of tests fail because they fail to deopt_one.
14:41 nwc10 jnthn: ASAN failures down to t/spec/S05-metasyntax/litvar.t t/spec/S05-transliteration/trans.rakudo.moar t/spec/S11-modules/require.rakudo.moar t/spec/S17-lowlevel/lock.rakudo.moar t/spec/integration/advent2010-day21.t t/spec/integration/advent2012-day10.t
14:41 nwc10 t/spec/S11-modules/require.rakudo.moar doesn't look to be an inline thing
14:42 jnthn Hm, I thought t/spec/S05-transliteration/trans.rakudo.moar was one of the ones I got clean...
14:42 jnthn And litvar.t wasn't failing ASAN so much as just failing due to a deopt_one issue
14:42 jnthn (Which I seem to have resolved locally)
14:43 lizmat t/spec/S11-modules/require seems to be a result of some S11 refactoring I did
14:43 lizmat investigating it atm
14:45 jnthn nwc10: Are you already wroking on valgrind'ing them for more details?
14:45 nwc10 was about to
14:45 jnthn nwc10: If not, hold on a bit for one more patch.
14:45 nwc10 OK
14:49 nwc10 jnthn: this is what ASAN says right now: http://paste.scsys.co.uk/394679
14:49 dalek MoarVM/inline: ff869d0 | jnthn++ | src/spesh/ (3 files):
14:50 dalek MoarVM/inline: Improve/correct DEOPT_INLINE annotations handling.
14:50 dalek MoarVM/inline:
14:50 dalek MoarVM/inline: Place them on the instructions that would oringally have carried a
14:50 dalek MoarVM/inline: DEOPT_ONE or DEOPT_ALL, rather than on the instruction afterwards.
14:50 dalek MoarVM/inline: review: https://github.com/MoarVM/MoarVM/commit/ff869d0671
14:50 jnthn litvar.t there didn't fail due to ASAN, though?
14:50 jnthn Ah, trans.rakudo.moar does fail with something though
14:51 jnthn But that seems to be the only ASAN one that could relate to inlines.
14:53 jnthn ah, and I know what that one is.
15:13 dalek MoarVM/inline: adaf646 | jnthn++ | src/core/interp.c:
15:13 dalek MoarVM/inline: Teach another lexical_types access about inlines.
15:13 dalek MoarVM/inline:
15:13 dalek MoarVM/inline: Hopefully resolves another of the ASAN complaints.
15:13 dalek MoarVM/inline: review: https://github.com/MoarVM/MoarVM/commit/adaf646f23
15:18 nwc10 before that commit it's down to t/spec/S05-transliteration/trans.rakudo.moar t/spec/S11-modules/require.rakudo.moar t/spec/S17-lowlevel/lock.rakudo.moar  t/spec/integration/advent2010-day21.t
15:18 nwc10 one of which is bogus
15:19 dalek MoarVM/inline: 785be4f | jnthn++ | src/6model/reprs/MVMStaticFrame.c:
15:19 dalek MoarVM/inline: GC mark the inline code ref.
15:19 dalek MoarVM/inline:
15:19 dalek MoarVM/inline: It'll almost always be gen 2, but can't be certain of that.
15:19 dalek MoarVM/inline: review: https://github.com/MoarVM/MoarVM/commit/785be4fef2
15:20 lizmat S11-modules/require should be fixed now
15:21 jnthn adaf646 probably moves the S05 and integration error further in rather than completely solving it.
15:45 dalek MoarVM/inline: 7a52289 | jnthn++ | src/core/frame.c:
15:45 dalek MoarVM/inline: Make lexical auto-viv inline-aware.
15:45 dalek MoarVM/inline: review: https://github.com/MoarVM/MoarVM/commit/7a52289d21
15:45 jnthn nwc10: OK, hopefully this nails all the inline-related fails.
15:47 nwc10 might be a delay in getting results - my laptop is being attacked by a one toothed monster
15:47 timotimo asan fails or all fails? :)
15:47 nwc10 at least it's only being grabbed. Not drooled on.
15:47 lizmat a fork gone wild?
15:47 jnthn timotimo: All afaik
15:48 timotimo oh!
15:48 timotimo ... as in: ready to merge into master?!
15:48 jnthn timotimo: Probably, though I was going to work on the improved allocation thing first, so we actually see the benefit...
15:48 timotimo great! :)
15:48 lizmat I would settle for fewer spurious S17 failures anytime
15:50 timotimo what should be the initial value for the supplies that haven't more'd yet?
15:50 timotimo oh, mischan
16:37 woolfy left #moarvm
16:38 nwc10 jnthn: only t/spec/S17-lowlevel/lock.rakudo.moar (with ASAN)
16:41 jnthn OK, great. Which isn't an inline issue.
17:51 nwc10 the files that valgrind previously found errors for are now clean. (except t/spec/S17-lowlevel/lock.rakudo.moar )
18:20 benabik joined #moarvm
18:28 zakharyas joined #moarvm
18:46 FROGGS hi everybody
18:47 japhb o/ FROGGS
19:36 colomon joined #moarvm
19:41 dalek MoarVM/inline: 7bcdf18 | jnthn++ | / (7 files):
19:41 dalek MoarVM/inline: Add a thread-safe fixed-size allocator.
19:41 dalek MoarVM/inline:
19:41 dalek MoarVM/inline: To be used in place of malloc/calloc/free for certain things. To get
19:41 dalek MoarVM/inline: malloc/free used again (for debugging), just set it to have zero
19:41 dalek MoarVM/inline: buckets.
19:41 dalek MoarVM/inline: review: https://github.com/MoarVM/MoarVM/commit/7bcdf183c1
19:41 dalek MoarVM/inline: 677812e | jnthn++ | src/spesh/candidate. (2 files):
19:41 dalek MoarVM/inline: Pre-calculate spesh-candidate work/env sizes.
19:41 dalek MoarVM/inline: review: https://github.com/MoarVM/MoarVM/commit/677812ec2f
19:42 dalek MoarVM/inline: e592f83 | jnthn++ | src/core/frame.c:
19:42 dalek MoarVM/inline: Used fixed size allocator for frames/work/env.
19:42 dalek MoarVM/inline: review: https://github.com/MoarVM/MoarVM/commit/e592f834fc
19:42 dalek MoarVM/inline: af4b7ad | jnthn++ | src/6model/reprs/MVMHash. (2 files):
19:42 dalek MoarVM/inline: Use FixedSizeAllocator for hash entries.
19:42 dalek MoarVM/inline: review: https://github.com/MoarVM/MoarVM/commit/af4b7adb29
19:55 vendethiel joined #moarvm
20:05 nwc10 jnthn: business as usual - only t/spec/S17-lowlevel/lock.rakudo.moar fails
20:29 jnthn nwc10: Oh. I get exit-time SEGVs in a few tests, which I can catch under the debugger.
21:06 dalek MoarVM/inline: 0f83217 | jnthn++ | src/core/threadcontext.c:
21:06 dalek MoarVM/inline: Frame cleanup needs StaticFrame; re-order cleanup.
21:06 dalek MoarVM/inline: review: https://github.com/MoarVM/MoarVM/commit/0f83217b9e
21:07 jnthn And that fixes it. :)
21:07 timotimo jnthn: with the allocator, do we get much improved performance already? or do you still need to build a cache on top of that?
21:07 jnthn timotimo: It seems to help a bit.
21:09 timotimo i can't reach my desktop at the moment, otherwise i'd offer to run some benchmarks
21:12 jnthn Well, inline doesn't help Rakudo a whole lot yet, 'cus I didn't yet teach it about frame handlers, and Rakudo pretty much always seems to spit one out at the moment for the return handler...
21:14 timotimo frame handlers are everything for exceptions and such?
21:14 timotimo hm, should we try to eliminate return handlers if we know we don't have a "return" statement?
21:15 jnthn I already looked into it and it's a little tricky
21:16 japhb jnthn: Have you done any segv fixes on master in the last few days?
21:17 timotimo how hard will frame handler merging be?
21:19 jnthn japhb: no
21:19 jnthn japhb: Though almost top of my todo list is to look at one Panda tests SEGV
21:19 timotimo ah
21:20 timotimo release is ~1 week in the future?
21:28 jnthn Thursday, I guess
21:29 timotimo that's the first day of the GPN :)
21:30 japhb GPN?
21:32 jnthn Hm. I just got my first sub-80s Rakudo build...
21:32 japhb Oooh
21:33 dalek MoarVM/inline: 8bb202e | jnthn++ | src/ (2 files):
21:33 dalek MoarVM/inline: Use the fixed size allocator for named used flags.
21:33 dalek MoarVM/inline: review: https://github.com/MoarVM/MoarVM/commit/8bb202e68c
22:29 * jnthn thinks inline is looking ok to merge
22:30 japhb \o/
22:33 mj41 joined #moarvm
22:58 timotimo that makes me a bit happy
22:59 timotimo though the missing handler handling leaves something to be desired
23:03 jnthn Well, it's one of various todos.
23:04 jnthn But better to bring improvements in incrementally.
23:04 timotimo 83.08user 1.27system 1:11.12elapsed 118%CPU (0avgtext+0avgdata 1127920maxresident)k
23:04 jnthn Rather than ever-lasting branches doing everything, but leaving opportunity for feedback to the end.
23:04 timotimo yays :)
23:05 jnthn grrr. I was wondering why a patch to eliminate more namesused and similar slowed things down.
23:05 jnthn So I pulled it out again to check and...still slower. Turns out iTunes is doing something expensive. :)
23:06 timotimo m)
23:07 timotimo in that case: feel free to push that patch :)
23:07 jnthn oh, and chrome tab with the latest England vs Italy info is chewing some too :)
23:13 timotimo 87.00user 1.05system 1:14.77elapsed 117%CPU (0avgtext+0avgdata 804048maxresident)k
23:13 timotimo without inline
23:13 jnthn ooh, so it's an improvement :)
23:14 dalek MoarVM/inline: 03e9cdf | jnthn++ | src/spesh/args.c:
23:14 dalek MoarVM/inline: Improve named arguments spesh.
23:14 dalek MoarVM/inline:
23:14 dalek MoarVM/inline: Can toss namesused checking op and thus the setting of the used flags.
23:14 dalek MoarVM/inline: This cuts down on ops, but should also allow more inlining.
23:14 dalek MoarVM/inline: review: https://github.com/MoarVM/MoarVM/commit/03e9cdf60a
23:14 timotimo i don't really know what's up with the difference in maxresident; probably due to using -j3 and different things ending up at the same time
23:15 jnthn Yeah...hmm
23:15 jnthn timotimo: Could you try wiht 03e9cdf?
23:16 timotimo sure
23:16 timotimo was just about to
23:18 timotimo 83.82user 1.21system 1:11.40elapsed 119%CPU (0avgtext+0avgdata 1129300maxresident)k
23:18 timotimo that's less elapsed, but more user
23:19 timotimo i should redo it with -j1
23:21 timotimo this is with inline, -j1:
23:21 timotimo 78.13user 1.16system 1:19.60elapsed 99%CPU (0avgtext+0avgdata 1129540maxresident)k
23:22 timotimo (waiting for laptop to cool off)
23:23 jnthn Hm, that's a real memory increase. Odd.
23:24 timotimo 81.69user 0.96system 1:22.96elapsed 99%CPU (0avgtext+0avgdata 803884maxresident)k
23:24 timotimo master with -j1
23:24 timotimo are our bytecode segments heavy on memory usage?
23:24 jnthn Not especially
23:25 jnthn I mean, the extra inlining can't account for *that* much difference.
23:25 timotimo yeah :\
23:25 jnthn oh...hmm
23:26 jnthn I think the graphs it makes when inlining maybe don't get freed up properly
23:26 timotimo that could surely explain things
23:27 timotimo if we free those up, we're going to lose some performance :P
23:28 jnthn Doubt it...it'll give us a smaller working set.
23:28 jnthn Leaking is never good cache wise.
23:28 timotimo oh, hm.
23:31 jnthn Working on a patch
23:41 jnthn timotimo: Think I got one :)
23:43 dalek MoarVM/inline: bfd79a7 | jnthn++ | src/ (4 files):
23:43 dalek MoarVM/inline: Don't leak graphs of spesh inlinees.
23:43 dalek MoarVM/inline: review: https://github.com/MoarVM/MoarVM/commit/bfd79a7e5d
23:43 woolfy joined #moarvm
23:44 jnthn Don't think it's the whole story, though...
23:56 jnthn Well, enough for today. 'night :)

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