Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2014-03-20

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

All times shown according to UTC.

Time Nick Message
01:05 jnthn *yawn*
01:05 jnthn I'll hunt that bug and cut the Moar release in the morning :)
01:05 jnthn Got too tired to do it now, after doing my other post-getting-internets-back errands.
01:05 jnthn 'night o/
01:08 japhb__ o/
02:04 colomon joined #moarvm
04:03 jnap joined #moarvm
05:04 jnap joined #moarvm
05:10 woosley joined #moarvm
06:04 jnap joined #moarvm
07:05 jnap joined #moarvm
07:57 FROGGS joined #moarvm
08:06 jnap joined #moarvm
08:10 zakharyas joined #moarvm
09:07 jnap joined #moarvm
09:33 nwc10 good *, MoarVM
09:34 FROGGS moin :o)
09:36 JimmyZ \o
09:53 zakharyas joined #moarvm
10:07 jnap joined #moarvm
11:07 sorear joined #moarvm
11:08 jnap joined #moarvm
12:09 jnap joined #moarvm
12:42 jnthn The "precompile a thing that uses native calls" bug is urgh
12:43 jnthn I think I know what's going on.
12:43 jnthn It's actually nothing directly to do with native call after all
12:48 nwc10 "can you fix it?"
12:56 jnthn Mebbe, though I may do the fix specific to Moar for now and bring other backends in sync.
12:57 jnthn One of those places where Moar's stricter, thread-safer, less-leaky closure model drops by to say, "huh, how can that ever work" :)
12:58 JimmyZ magic
12:58 FROGGS I like that MoarVM is stricter btw, because we found quite some absurdities this way
12:59 jnthn aye
12:59 jnthn Also we need to switch JVM over at some point
12:59 jnthn There are some nasty things lurking
12:59 FROGGS urgh
12:59 jnthn In the way it currently does it, I mean.
13:10 jnap joined #moarvm
13:14 JimmyZ Does panda work with p6-m?
13:17 jnthn Believe so.
13:17 jnap joined #moarvm
13:21 tadzik it does
13:21 tadzik p6-m is OP
13:24 JimmyZ I thought it doesn't , I tried it on x64 and failed
13:24 JimmyZ about two days ago
13:24 jnap1 joined #moarvm
13:32 jnthn err& # will get back to Rakudo fix in a bit
13:55 btyler joined #moarvm
14:05 ingy^ joined #moarvm
14:05 ingy^ left #moarvm
14:43 colomon joined #moarvm
16:06 jnthn OK, back to looking at it... :)
16:34 FROGGS joined #moarvm
17:47 dalek MoarVM: 7b55013 | jnthn++ | docs/ChangeLog:
17:47 dalek MoarVM: A couple more ChangeLog entries.
17:47 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/7b55013da6
17:52 dalek MoarVM: 3ac0ecb | jnthn++ | VERSION:
17:52 dalek MoarVM: Bump VERSION.
17:52 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/3ac0ecbe5c
18:01 jnap joined #moarvm
18:32 dalek moarvm.org: cd91073 | jnthn++ | / (4 files):
18:32 dalek moarvm.org: Update site for 2014.03 release.
18:32 dalek moarvm.org: review: https://github.com/MoarVM/moarvm.org/commit/cd91073437
18:32 jnthn Release cut.
18:47 nwc10 \o/
18:51 tadzik alright :)
18:52 tadzik I should be back home in 30-40 minutes, and I'll start the release process
19:02 brrt joined #moarvm
19:02 brrt hi #moarvm
19:04 nwc10 hi brrt
19:04 brrt hi nwc10
19:05 brrt i think i have a reasonable idea on how to create a JIT compiler now
19:05 nwc10 outsource it to edument? :-)
19:05 brrt lol
19:05 nwc10 This is perl 5, version 19, subversion 10 (v5.19.10) built for aix
19:05 nwc10 oh, wrong channel
19:06 brrt - step 1: create tracing insfrastructure (ops, tables, etc) for recording type / method information
19:07 brrt - step 2 (with many substeps): create a 'recompiler' that takes MVM bytecode, acts as if its a three-address-code (which it is), and compiles it to a simpler 'core' bytecode
19:08 brrt step 2 is maybe already the step where we add speculative type-feedback to the compilation
19:08 brrt step 3: take this highly simplfied 'core' bytecode and compile it to native bytecode using something like dynasm
19:09 brrt why go through all this trouble to create not one but 2 compilers? because mvm has >500 ops right now
19:13 jnthn Hm, looks like you're going straight to trace JIT with doing the step 1 stuff..
19:14 brrt ....
19:14 jnthn As for step 2 - I agree that something between the bytecode and assembly for a particular backend can help.
19:15 brrt waitaminute, i'm thinking exactly how i should phrase this
19:15 brrt yes
19:15 jnthn But you'll want to go to that lower-level thingy from the CFG/SSA data strucutre I'm working on, I suspect. Not directly from the bytecode.
19:15 brrt yes
19:15 brrt exactly
19:15 brrt but you'll be basing that on top of the mvm bytecode, right?
19:15 jnthn It starts from the bytecode and makes the data structure, yes
19:15 brrt i've forgot what cfg is? call flow graph?
19:15 jnthn Control flow graph
19:15 jnthn Within a procedure.
19:15 brrt clear
19:16 jnthn Thing is, we can do all the stuff like inlining, type specialization, and escape analysis at that level.
19:16 jnthn And then JIT the results of that.
19:16 brrt ok, do you think i can say 'step 1 - create a graph representation of mvm bytecode' in my proposal
19:17 jnthn That's reasonable, and "collect type information" also is.
19:17 brrt ok
19:18 jnthn Though I think we'll end up sharing that with the bytecode specializer. As I see it, on platforms where we can JIT and we know how to JIT all the ops, we can go ahead and do so. When we don't, we can fall back to producing specialized bytecode that will still be a good speed win.
19:18 jnthn We may even want to JIT those asynchronously at some point.
19:19 jnthn But that's not something you need to worry over right now :)
19:19 brrt i've had good ideas about that i think
19:19 brrt i'll let you know
19:22 brrt by the way, there is another thing
19:22 brrt somewhere in MVM documentation it says 'nested runloops - just say no'
19:22 brrt which is dandy, but it will be a problem - or may be a problem - for JIT-ed code
19:23 brrt because - how am i to know if a procedure that i'm calling will also be JIT-ed
19:23 nwc10 s/may even/likely will/ ?
19:23 brrt i think thats right :-)
19:24 nwc10 it's a good use of another core, if nothing else wants it
19:25 brrt oh, you mean asynchronous JIT-ing
19:25 brrt v8 does that now
19:25 brrt vms are such hotness these days
19:26 nwc10 IIRC Unladen Swallow saw that Rubinius was doing it, and planned to
19:27 brrt there are problems with that, though
19:28 brrt some of the problems already appear in MoarVM - being that (in principle) the reference to a particular code segment could be changed from under an executing thread
19:29 brrt i.e. bytecode is somewhat assumed to be immutable, isn't it?
19:29 brrt and JIT-ing means replacing a part of bytecode with native code
19:29 brrt so somehow, users of that code will need to be notified
19:31 jnthn So long as we can publish the availability of the JITted version as a single pointer update, we're good. And I think we can.
19:31 jnthn The invocation handler will just notice it's available next time around.
19:32 jnthn On the nested thing - if the next target ain't JITted, we can just save the return address in the JITted code and call back out into the interpreter.
19:32 brrt hmmm... won't that need a special new op?
19:32 brrt return-to-native-code?
19:34 jnthn Probably.
19:34 brrt thats ok i guess
19:34 jnthn I suspect we'll have an enterjit/exitjit secret op :)
19:35 jnthn Worth it to keep the stack shallow :)
19:36 brrt i agree
19:36 brrt consider also exceptions
19:36 brrt that wasn't proper english
19:41 jnthn Yeah, though exceptions are really a jump or an invocation. But yes, they'll be a bit of fun :)
19:42 FROGGS interesting to see consensus on that topic :o)
19:42 brrt they're doable in a 'single runloop' situation, not so much for nested ones
19:42 jnthn Yeah, those and continuations are two reasons I've avoided them.
19:44 tadzik I wonder how much should I say about MoarVM in the Rakudo release announcement
19:44 tadzik like "huge amount of improvements on moarvm backend", or "moarvm backend is now practically as capable as parrot backend"?
19:45 brrt moarvm goes to the moon?
19:45 tadzik and beyond!
19:45 cognominal moarvm is a chinese thing?
19:46 tadzik moon, not mun :P
20:10 brrt ok, i have a few more steps for JIT-ing to the moon
20:11 brrt step N: create a runloop from JIT-able fragments using dynasm
20:11 brrt step N+1: generate native bytecode from said JIT-able fragments
20:19 masak jnthn++ # 2014.03
20:35 hoelzro is there a changelog for 2014.03?
20:37 jnthn yes
20:39 tadzik hmm. Is 'make stresstest' still a thing
21:09 japhb__ jnthn: Did you manage to find that perl6-debug-m segfault?
21:10 FROGGS I think I've seen a patch, dunno if it was related
21:11 jnthn japhb__: Yeah
21:11 japhb__ \o/
21:11 jnthn japhb__: You'll want an updated Debugger::UI::CommandLine
21:12 jnthn japhb__: However, there is one slightly unfortunate behavior.
21:12 japhb__ OK, since I rebuild everything anyway, that should be no problem.
21:12 japhb__ Oh?
21:13 jnthn The debugger breaks on thrown exceptions, giving you a chance to understand what's wrong even in a program that you puts lots of error handlers into so the exceptions are never actually unhandled.
21:13 jnthn And it just turns out that the code that handles parameters tries to parse them all using numbers, then catches the resulting failure for non-numeric args.
21:14 jnthn So the first thing the debugger does now is tell you about a number fails to parse exception :)
21:14 jnthn I don't immediately have a good answer to that.
21:15 nwc10 how about "buy jnthn beer, to help him think"? :-)
21:16 japhb__ Heh.
21:17 jnthn heh :)
21:36 colomon joined #moarvm
22:06 brrt joined #moarvm
22:21 brrt joined #moarvm
22:27 brrt left #moarvm

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