Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2015-09-07

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

All times shown according to UTC.

Time Nick Message
00:27 colomon joined #moarvm
01:20 [Coke] timotimo: shorter to write -j
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
02:19 _longines_ joined #moarvm
02:21 JimmyZ joined #moarvm
02:29 nwc10_ joined #moarvm
02:30 orbus joined #moarvm
02:42 colomon joined #moarvm
03:07 nebuchad` joined #moarvm
03:09 xiaomiao joined #moarvm
03:13 harrow joined #moarvm
03:17 TimToady joined #moarvm
03:19 _longines joined #moarvm
04:26 tokuhiro_ joined #moarvm
04:30 dalek joined #moarvm
05:20 ShimmerFairy joined #moarvm
06:08 vendethiel joined #moarvm
06:08 FROGGS joined #moarvm
07:07 Ven joined #moarvm
07:34 lizmat joined #moarvm
07:56 lizmat joined #moarvm
08:02 lizmat joined #moarvm
08:11 lizmat joined #moarvm
08:45 Ven joined #moarvm
09:49 rarara joined #moarvm
10:11 ShimmerFairy joined #moarvm
10:13 Ven joined #moarvm
10:42 brrt joined #moarvm
11:16 Ven joined #moarvm
11:51 Ven joined #moarvm
11:55 brrt good *
12:16 jnthn o/ brrt
12:16 brrt how is today? :-)
12:17 * brrt kind of has post-yapc start-of-academic-year blues
12:17 brrt i don't want to start doing responsible things
12:18 nwc10 I am having massive difficulty concentrating
12:18 nwc10 despite knowing what I want to do, and having a reasonably good idea how to do it
12:18 * jnthn is still exhausted
12:19 jnthn Though I seem to be getting past the mental exhaustion some
12:20 jnthn Still some way to go on the physical, though feel notably icky today 'cus my guts have decided to be unhappy (a fairly typical delayed-reaction-to-stress thing for me)
12:20 brrt ah, that sucks
12:21 brrt hope it get's better soon
12:21 jnthn Yeah. Means I need to eat boring stuff for a while
12:21 brrt gets
12:21 jnthn Though my wife insists it's not boring, but healthy :)
12:21 brrt in case you're not gluten-sensitive, i can recommend oatmeal :-)
12:21 brrt yes, terribly hipster food, but also boring and healthy :-)
12:21 jnthn I'm not :)
12:22 brrt fortunately
12:22 jnthn Hm, I wonder if oatmeal stout also helps... ;)
12:22 brrt i'm not sure...
12:22 * jnthn decides not to do that experiment
12:22 nwc10 jnthn: mine also do that after various foods, particularly some that I enjoy (eg Indian)
12:22 jnthn Oatmeal stout can be a very good drink, though.
12:23 brrt nwc10: re: the pypy / rpython thing. i've been sufficiently critical of that approach on other times
12:23 brrt but at least the pypy guys themselves believe that their approach can be generalized to other systems
12:23 jnthn nwc10: I've eaten Indian at least once a week for 20 years, so it normally has little effect; in fact, in normal conditions Indian food (if not stupidly hot) tends to have a calming effect.
12:23 brrt surprisingly few other teams do, but i'm not sure what that says about whom
12:23 nwc10 could you clarify "that approach"? Something about how they don't see their project as a VM?
12:24 nwc10 at least, the VM-like bit of their project not actually being a VM.
12:24 brrt well, it seems to me they have succesively tried to abstract away from the icky bits of writing a VM and JIT
12:24 nwc10 (nothing wrong with PyPy. Just how they self-describe)
12:25 brrt and wrote a meta-meta-meta-compiler-vm-jit thingy that ultimately resolves to a (very decent) JIT+interpreter system
12:26 brrt so yeah. it's great for them. but i don't think it's been a practical approach
12:26 brrt nevertheless, they're years ahead of us
12:28 nwc10 for now. We can iterate configure/build/test cycles much faster than they can.
12:31 brrt yes. and we've access to the papers written in the meantime :-)
12:34 nwc10 what I'm also curious about is that the pypy release rate has slowed down.
12:34 nwc10 Now we have 2.6.1 about 3 months after 2.6: http://morepypy.blogspot.co.at/2015/08/pypy-261-released.html
12:34 nwc10 we used to have 2.$n+1 about 3 months after 2.$n
12:35 brrt well, they're 10 years old or so
12:35 nwc10 not sure if they're scared of reaching 2.7
12:35 nwc10 let alone 2,8
12:35 brrt so they must have had a slower release date earlier
12:35 nwc10 er, 2.8
12:35 brrt hmm, yeah, i guess i can see why not :-)
12:45 Ven joined #moarvm
12:50 brrt we're halfway through compiling a single 170-node expr tree
12:53 brrt as a wise man once said, 'brrt, your assumptions suck' :-P
12:53 FROGGS *g*
12:57 brrt one of the things that i still want to do, is convert the tree structure back to linear structure, interleaved with 'special' tiles that do al the labelling magic now
13:00 timotimo o/
13:07 dalek MoarVM/even-moar-jit: 821738c | brrt++ | src/jit/ (3 files):
13:07 dalek MoarVM/even-moar-jit: Fix a set of register allocator bugs
13:07 dalek MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/821738c609
13:07 brrt \o timotimo
13:07 jnthn .oO( If you made the same bug twice, would you be disciplined enough to say you fixed a bag of bugs? )
13:08 timotimo brrt: how can you tell how far the compiler makes it? when i try to run something that uses it, i end up with a very unhelpful stack trace inside gdb :)
13:08 timotimo well, i *could* probably disassemble and have a closer look, but ... enh
13:09 brrt well, the compiler makes it to the end if it doesn't burn into flames
13:09 brrt so you don't have to worry so much about that
13:09 brrt (i'm not sure if i would jnthn)
13:10 brrt anyway, i do actually disassemble and inspect registers and stuff
13:10 brrt i have a little gdb script that sets up moar+nqp for me
13:10 timotimo you as the jit author are expected to :)
13:10 timotimo me as a "be amazed and cheer from the sidelines" type of person ... not so much :))
13:11 brrt yeah, i kind of expected that
13:12 brrt hmm
13:12 brrt oh, and i have MVM_JIT_BYTECODE_DIR set obviously
13:12 timotimo of course :)
13:13 timotimo i bet the generated code already looks a lot nicer than the old code used to :)
13:13 timotimo what with all the repeated loads and stores partially removed :)
13:14 brrt 'a lot' - i'm kind of sceptical there
13:14 brrt also
13:14 brrt there's a bug in the kitchen
13:14 brrt as in
13:15 timotimo an insect trying to nom all your food?
13:15 brrt i'm fairly sure i never do [reg1+reg2*4+0x48]
13:15 timotimo hm
13:15 brrt no, these are just my rats....
13:15 timotimo :)
13:16 brrt ok, i see
13:16 timotimo i forgot, we don't have common subexpression elimination, right?
13:16 timotimo so the code is possibly a bit bloated at the moment? because we duplicate things all the time so we can properly tile the tree?
13:20 brrt we don't have CSE, indeed
13:20 brrt yes, our tree is bloated
13:20 brrt no, that isn't to help tiling
13:20 brrt actually
13:21 brrt we do duplicate nodes to resolve tile conflicts
13:21 brrt but that's not the same as lacking CSE
13:21 timotimo mhm
13:22 timotimo well, CSE would help that, i imagine
13:22 timotimo that's why i lumped them together
13:23 brrt yeah, CSE could do nice things
13:23 brrt one of the nicer things still is to automatically order computations shared between branches before the branch
13:24 timotimo ah, invariant code hoisting or something like that
13:25 brrt it's a correctness issue. code hoisting is also really cool but i'm not sure if most effect would not be had at the spesh level
13:27 jnthn Possibly.
13:27 brrt looks like i have another code-generation bug on my hands
13:28 jnthn Me too :)
13:29 jnthn Though mine is the QAST -> JAST one I think others already banged their heads against for 10 hours...
13:37 brrt fun times :-)
13:37 FROGGS no.
13:38 jnthn wtf
13:38 jnthn Yeah, it's odd alright
13:38 FROGGS hehe
13:39 timotimo jnthn: did you know the optimizer has a flag called "flattened" that "incorporate_inner" expects to be set if an inner block has been flattened, but we only initialize it to 0, never set it to 1? :)
13:40 timotimo sadly, setting it after having done a flattening operation reveals a problem that has been hidden before :|
13:40 FROGGS timotimo: do not disturb him nao!
13:40 timotimo oh
13:40 FROGGS :D
13:40 jnthn timotimo: I suspect that's a case of "I stole the logic from NQP but didn't get so far as making it work as well as NQP" :)
13:40 timotimo right, i just expected a short comment about it
13:40 jnthn FROGGS: With the JVM build times I've all the time in the world :P
13:40 FROGGS jnthn: hehe
13:41 jnthn It really does seem to get the tree for the entire CORE.setting just about
13:42 timotimo jnthn: with my lex-to-loc branch it's even worse; there seems to be some oversharing going on that causes a QAST::Var to be turned into a local in a block that's in some totally different place :|
13:42 jnthn What's really odd is that it shouldn't get that far
13:42 jnthn Because nqp::p6configposbindfailover isn't implemented for the JVM
13:42 jnthn But it should blow up saying so
13:43 FROGGS ohh
13:43 jnthn Somewhere along the way
13:43 jnthn Not get to the end and have a null
13:45 FROGGS jnthn: how did you find out that this op is not implemented?
13:47 jnthn FROGGS: I didn't; I just knew it was the only added op, and was in that code a moment ago fixing the multi-dispatcher, and thought to search for it and found it's missing on JVM :/
13:47 jnthn I'm currently trying to work out why it didn't explode
13:48 rarara For me, it is surprising that they Pypy people claim an improvement on simple cycles which sum two vectors using SIMD. I did many tests douring my phd and that didn't work. Check for instance this https://gist.github.com/anonymous/7dca6d4b7dbd12c19fb4    (gcc -S -mavx -std=gnu99 -O3 source.c)   the nonparallelized run is faster for me; I don't think i'm making errors
13:51 rarara (-S is for see code, run gcc without to compile)
13:52 rarara Non optimized, passed 0 sec and 450765901 nanosec Optimized, passed 0 sec and 467647205 nanosec Result checked!
14:13 FROGGS jnthn: do you also observe that we hit the CATCH block twice in as_jast(QAST::Op ...)?
14:15 jnthn FROGGS: I decided to work on getting JVM closer to working with GLR rather than investigating the error reporting issue
14:15 jnthn (The latter is worth doing but with something rather smaller than CORE.setting ;))
14:15 FROGGS jnthn: np, I can do that :o)
14:17 jnthn FROGGS: OK
14:17 jnthn FROGGS: I'm about to push a patch that clears up the JVM guts-y code some
14:17 jnthn And adds throws to point out code that needs updating
14:18 jnthn (rather than it exploding with odd errors)
14:18 jnthn Do you want to take on filling those few bits out?
14:27 jnthn .oO( Or is FROGGS not going to answer that until I've actually ended up doing them... :P )
14:35 FROGGS *g*
14:35 FROGGS I can take over filling holes I think
15:20 FROGGS[mobile] joined #moarvm
15:20 ShimmerFairy joined #moarvm
15:26 psch joined #moarvm
15:53 FROGGS joined #moarvm
16:25 Ven joined #moarvm
17:17 Ven joined #moarvm
17:50 Peter_R joined #moarvm
17:54 tokuhiro_ joined #moarvm
18:31 vendethiel joined #moarvm
18:55 tokuhiro_ joined #moarvm
20:14 brrt joined #moarvm
20:14 brrt rarara: my suspicion is that this is related to a fewer total number of iterations in the vectorized case for pypy
20:15 brrt i.e. the iterating loop isn't totally optimal, hence reducing the iterations increases the performance
20:16 tokuhiro_ joined #moarvm
21:06 lizmat joined #moarvm
21:22 lizmat_ joined #moarvm
21:55 lizmat joined #moarvm
22:01 psch joined #moarvm
22:17 tokuhiro_ joined #moarvm
23:03 FROGGS joined #moarvm
23:19 Peter_R joined #moarvm
23:35 FROGGS joined #moarvm

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