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