Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2015-05-16

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

All times shown according to UTC.

Time Nick Message
01:28 vendethiel joined #moarvm
01:49 ilbot3 joined #moarvm
01:49 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
03:14 danaj joined #moarvm
03:45 FROGGS_ joined #moarvm
04:05 dalek MoarVM: c2c49cb | timotimo++ | src/jit/emit_x64.dasc:
04:05 dalek MoarVM: emit add, sub, bor, band, bxor with constant if possible
04:05 dalek MoarVM:
04:05 dalek MoarVM: we end up doing one of these two variants 157 times during a
04:05 dalek MoarVM: full rakudo compile; sadly it only saves a single mov instruction
04:05 dalek MoarVM: if the source and target registers are the same, but it removes
04:05 dalek MoarVM: stack access in any case.
04:05 dalek MoarVM:
04:05 dalek MoarVM: i expect the next generation of our jit to do this kind of opt
04:05 dalek MoarVM: automatically for pretty much every operation, but that is not now.
04:05 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/c2c49cbaad
04:05 timotimo i had this nagging thought and it prevented me from falling asleep ... :P
04:06 timotimo next step could be to remove any const_i instruction that becomes useless due to this
04:43 * timotimo has another patch handy that'll improve generated code size a bit more
04:44 timotimo we often do getspeshslot for different spesh slots into the same register twice in a row; my current patch kind of fixes the symptom, but ideally the code that emits the second getspeshslot ought to be smart enough to re-use the previous spesh slot (that would also reduce the size of spesh'd frames)
04:44 timotimo and since a getspeshslot is two movs, we can save 2 movs very, very often
04:45 timotimo bytes and bytes and bytes of instructions saved!
04:50 dalek MoarVM: d75a612 | timotimo++ | src/spesh/optimize.c:
04:50 dalek MoarVM: kill duplicate getspeshslot ins for the same register
04:50 dalek MoarVM:
04:50 dalek MoarVM: ideally, the piece of code that generates these would
04:50 dalek MoarVM: re-use the previous spesh slot, but that's for someone
04:50 dalek MoarVM: more awake to do.
04:50 dalek MoarVM:
04:50 dalek MoarVM: turns 4 mov instructions into 2.
04:50 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/d75a612824
04:54 timotimo m: all frames compiled during a full rakudo compilation now take only { 906436 / 915831 } as many bytes"
04:54 camelia rakudo-moar 55ed38: OUTPUT«===SORRY!=== Error while compiling /tmp/KyuOeAvQ4M␤Two terms in a row␤at /tmp/KyuOeAvQ4M:1␤------> led during a full rakudo compilation now⏏ take only { 906436 / 915831 } as many b␤    expecting any of:␤        infix␤        infi…»
04:54 timotimo m: say "all frames compiled during a full rakudo compilation now take only { 906436 / 915831 } as many bytes"
04:54 camelia rakudo-moar 55ed38: OUTPUT«all frames compiled during a full rakudo compilation now take only 0.9897416 as many bytes␤»
04:54 timotimo hm, only 1% saved?
04:55 timotimo m: say "all frames compiled during a full rakudo compilation now take only { 100 * 906436 / 915831 }% as many bytes"
04:55 camelia rakudo-moar 55ed38: OUTPUT«all frames compiled during a full rakudo compilation now take only 98.9741557% as many bytes␤»
07:30 brrt joined #moarvm
07:30 brrt hold on timo :-)
07:30 brrt that patch will only work when the constant is small (< 32 bits wide)
07:31 brrt i'm not sure if it is true for all of x86-64, but if i recall correctly most opcodes can only take a 32 bit immediate value
07:31 brrt (that said, it is a pretty nice fix :-))
07:52 brrt now i'm looking for a good way to check if a number fits into 32 bit; and a further complexity is negative numbers
08:03 brrt (pushed changes to dynasm, by the way)
09:14 vendethiel joined #moarvm
09:28 nwc10 jnthn: I baked you a branch, called version-bump
09:28 nwc10 at https://gitlab.com/nwc10/MoarVM.git (which I think you have as a remote "nwc10")
09:31 * jnthn looks
09:33 jnthn 1c86576486221 lies!
09:33 Peter__R joined #moarvm
09:33 jnthn uh, well, it's confusing :)
09:33 TimToady_ joined #moarvm
09:33 jnthn But either way, if we're bumping to 5, then this line:
09:34 jnthn MVMuint16 slvs = cu->body.bytecode_version >= 4 ? read_int16(pos, 40) : 0;
09:34 jnthn Need not stay
09:34 nwc10 oh bother.  I missed one?
09:34 jnthn Two :)
09:34 nwc10 jnthn++ # review
09:34 nwc10 I fail
09:35 nwc10 I shall have another go, and get better at double checking grep
09:36 jnthn :)
09:39 dalek MoarVM: 2b14b67 | nicholas++ | src/6model/serialization.c:
09:39 dalek MoarVM: Bump minimum serialization format version.
09:39 dalek MoarVM:
09:39 dalek MoarVM: Now that we've rebootstrapped, we no longer need the code to read older
09:39 dalek MoarVM: serialization versions.
09:39 dalek MoarVM:
09:39 dalek MoarVM: Again, mostly removal of if statements with ...->root.version checks, and
09:39 dalek MoarVM: re-indenting because of the blocks this eliminates.
09:39 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/2b14b6788b
09:39 jnthn That one was fine, so it's in
09:54 nwc10 thanks
10:18 nwc10 stupidity should now be fixed as a branch version-bump1
10:20 jnthn Thanks, looks better
10:20 nwc10 sorry about the previous cock up
10:23 jnthn np
10:23 jnthn That's what review is for
10:25 nwc10 agree. but I should have spotted them
10:29 dalek MoarVM: 9349f87 | nicholas++ | src/core/bytecode.c:
10:29 dalek MoarVM: Formally bump minimum bytecode version to 5.
10:29 dalek MoarVM:
10:29 dalek MoarVM: The code suggests that versions back to 2 are supported, but it has effectively
10:29 dalek MoarVM: been at 4 for a very long time, because there is conditional code relating to
10:29 dalek MoarVM: earlier versions. Additionally, the serialization blobs of earlier bytecode
10:29 dalek MoarVM: files would be rejected, because they will be using a serialization format
10:29 dalek MoarVM: version we now no longer support.
10:29 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/9349f875ed
10:36 timotimo brrt, that's not a problem, the only constants ever used were 1, 2, 3, 4 and 255 ;)
10:42 timotimo the dynasm changes don't seem that immense :S
10:44 jnthn They looked like a few patches from upstream
10:44 jnthn Grr, the remaining explosion in the concurrent-restarter thing is proving rather tricky to locate
10:48 timotimo the only change that looks like a bugfix or so is in the arm module, which we don't use yet
10:49 timotimo and in x86 and 64 we get support for some environment saving/restoring ops, looks like
10:50 timotimo i was quite surprised to see that one of the biggest frames we compile is actually ws
10:50 timotimo but ws in rakudo is quite involved, and it probably inlined some things?
10:50 timotimo i wonder if i should try to compact the sslots?
10:51 timotimo first i ought to put in some logging to see how many sslots are saved in how many frames
10:53 jnthn It probably inlined some things, yes
10:54 timotimo it's at about 10 kilobytes
10:55 jnthn Of JITted output?
10:55 timotimo i think i want to put in removal of the cheapest of BB "redirections" where we have BBs that consist of a single goto
10:55 timotimo yes
10:55 jnthn So JIT
10:58 timotimo very
10:59 timotimo does much stand in our way to move blocks from inlined spesh graphs much closer to where they were inlined to?
11:00 timotimo i expect a long jump would for sure kill many instruction cache lines
11:00 timotimo especially since we don't have any code (as far as i can tell) to align bbs (or much of anything)
11:03 jnthn It may not be overly bad. It's an unconditional branch, so it's predictable
11:03 jnthn Not a lot stands in our way. I know we can't do it for ones that deopt.
11:03 jnthn Uh, at least I think wecan't
11:03 jnthn *we can't
11:08 jnthn m: say 0x016e
11:08 camelia rakudo-moar 652c24: OUTPUT«366␤»
11:09 timotimo in ws we generate a jumplist instruction and then a bunch of BBs that are exclusively a single goto statement
11:09 timotimo 19 of those in a row
11:09 timotimo those BBs, i mean
11:09 jnthn uh, wow...it seems the $vow.keep call is failing 'cus somehow keep ends up getting resolved to Null
11:09 timotimo we seem to be doing that for every jumplist
11:09 timotimo o_O
11:10 timotimo "cannot invoke this representation: null"?
11:10 jnthn Right
11:15 jnthn I would suspect method cache lazy deserialization except...it looks correct
11:15 jnthn (as in, already has appropriate concurrency control)
11:25 * jnthn away for a bit
11:27 timotimo i wonder in what cases i have to bail out because of handlers and such
11:31 timotimo oh, we may not be able to move inlined BBs to the inlining block if they are inside a handler's scope, as they follow the linear order
11:37 Peter_R joined #moarvm
11:55 timotimo in spesh's manipulate.c, the remove_successor function uses MVM_throw_exception_adhoc, which might want to be a panic instead? (because having that be catchable is kinda weird)
11:56 timotimo but we don't have a specific exitcode for spesh-related errors yet
12:38 vendethiel jnthn++ # blog
13:05 brrt joined #moarvm
14:11 timotimo something i'm doing with shuffling preds and succs around makes the code end up in the interp loop with a tc of null
14:32 timotimo i can't seem to spot the mistake :\
14:34 dalek MoarVM/union_goto_chains: 1023164 | timotimo++ | src/spesh/optimize.c:
14:34 dalek MoarVM/union_goto_chains: try to turn chains of two gotos into a single one
14:34 dalek MoarVM/union_goto_chains:
14:34 dalek MoarVM/union_goto_chains: currently dies when trying to find ourselves as
14:34 dalek MoarVM/union_goto_chains: a succ's pred after it worked a single time
14:34 dalek MoarVM/union_goto_chains: review: https://github.com/MoarVM/MoarVM/commit/1023164a9c
14:34 timotimo ^- maybe someone can spot the problem?
15:02 dalek joined #moarvm
16:06 brrt joined #moarvm
16:19 TimToady joined #moarvm
16:38 dalek MoarVM: f23e56a | brrt++ | src/jit/emit_x64.dasc:
16:38 dalek MoarVM: JIT - check if constant value fits in 32 bit
16:38 dalek MoarVM:
16:38 dalek MoarVM: This checks if the constant value in an arithmetic operation
16:38 dalek MoarVM: actually fits in the 32 bits immediate value size limit of x86.
16:38 dalek MoarVM: Usually that will be true, but we'd better be safe than sorry.
16:38 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/f23e56a5c4
16:39 brrt so, that gives me a bit of peace :-)
16:40 brrt i must say, timotimo++ for the creativity with which you find optimisation possiblities
16:41 * brrt afk &
16:41 brrt left #moarvm
17:18 zakharyas joined #moarvm
17:27 timotimo i just look at spesh output and jit output and things become obvious ;)
18:05 zakharyas joined #moarvm
18:26 FROGGS :o)
18:27 cygx joined #moarvm
18:27 cygx oO( You get used to it, though. Your brain does the translating. I don't even see the code. All I see is blonde, brunette, redhead. )
18:28 cygx timotimo: ^^
18:29 FROGGS *g*
18:34 timotimo also, brrt, i find your compliment slightly exaggerated
18:55 TimToady he was being creative :)
19:08 timotimo hah
19:56 brrt joined #moarvm
19:57 brrt \o (for a few minutes)
19:58 brrt i don't think i'm exaggerating though :-)
19:58 brrt anyway... i'm reading the luajit2 code...
19:58 brrt i'm really glad we're using dynasm for code generation so far
20:01 brrt also... i still think i'd want to add a new 'failure function' for moarvm internally
20:01 jnthn brrt: A panic with more info?
20:01 brrt so that we can let users know we screwed up, without throwing catchable exceptions
20:01 brrt yes
20:01 jnthn Any reason not to adapt panic?
20:02 brrt well. i was told panic would happen only if we weren't sure our memory layout was still correct
20:02 jnthn Hm, point
20:02 brrt so in that case, you can't go ahead and try and make a backtrace
20:02 jnthn *nod*
20:02 brrt i'm talking about the cases wherein we MVM_exception_throw_adhoc()
20:03 brrt maybe we should call it MVM_we_did_something_dumb()
20:03 brrt MVM_oops() :-)
20:05 jnthn A lot of MVM_panics today aren't actually at "we're SO hosed!" points
20:06 dalek MoarVM: 0551316 | FROGGS++ | src/6model/serialization.c:
20:06 dalek MoarVM: cope with null string in sc->body->description in ex
20:06 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/05513165bc
20:07 brrt hmmm
20:07 jnthn I agree we should split the two, though.
20:07 jnthn One for extreme "we're out of or corrupted memory" situations that prints a message and gets out
20:08 jnthn And another for the rest of the time
20:08 * brrt nods
20:08 jnthn Don't mind too much on naming
20:09 brrt no, neither do i; for some reason that doesn't make it much simpler :-P
20:12 brrt hmm, it'd be really simple just to MVM_dump_bactrace()
20:12 brrt assuming stderr is a reasonable place to dump it
20:12 jnthn Yeah
20:12 jnthn That means we need a tc
20:13 jnthn Which is fine if we're not in a memory-hosed situation
20:14 brrt right
20:15 brrt i see a particularly sneaky error now; throwning a lexotic from the JIT might result in throwing an adhoc if no matching offset can be found
20:15 brrt if you're expecting something thrown, there's a reasonable chance not to figure out that something unrelated was thrown
20:18 brrt do we want to pass an error code?
20:21 jnthn Not sure an error code helps a great deal
20:21 jnthn A unique message is far more helpful
20:22 jnthn ('cus we know where in the code we paniced)
20:22 brrt a lexotic is always a control exception, isn't it?
20:22 jnthn Yeah
20:22 brrt right, got it
20:23 brrt do we want those (lexotics) - when they fail - to throw an exception, or to semi-panic?
20:23 brrt right now these functions throw adhoc exceptions
20:23 TimToady you mean like the 9 places that can throw ");
20:23 TimToady oops
20:23 TimToady ... Cannot look up attributes in a type object
20:24 jnthn TimToady: That's a regular, catchable, exception, not a panic.
20:25 jnthn We're talking about panics, where we get into an unrecoverable mess.
20:25 jnthn Of course, can factor the throwing of the "cannot look up attributes in a type object" one out into a single function that we call to throw it
20:25 brrt or, in my case, messes that are recoverable in theory, but very much a VM programmer error (rather than a perl6 programmer error)
20:26 jnthn brrt: True
20:27 jnthn Anyways, I'm off for the evening, to get some rest
20:28 jnthn o/
20:30 brrt rest well :-)
20:35 cygx left #moarvm
20:36 FROGGS that one is new:
20:36 FROGGS src/jit/emit_x64.dasc:637:17: warning: format ‘%d’ expects argument of type ‘int’, but argument 4 has type ‘MVMint64’ [-Wformat=]
20:36 FROGGS MVM_jit_log(tc, "accumulator for %s stayed in memory and constant value %d used\n", ins->info->name, value);
20:37 zakharyas joined #moarvm
20:38 TimToady sure woulda been nice if the inventors of printf had figured out how not to duplicate the type system in the formats
20:39 dalek MoarVM/curly: 2f0cf28 | FROGGS++ | / (8 files):
20:39 dalek MoarVM/curly: add scdisclaim op
20:39 dalek MoarVM/curly:
20:39 dalek MoarVM/curly: This way we can deserialize an serialization context (SC), throw the SC away, and then serialize
20:39 dalek MoarVM/curly: the obtained object to another SC.
20:39 dalek MoarVM/curly: review: https://github.com/MoarVM/MoarVM/commit/2f0cf28da1
20:41 brrt FROGGS - will fix :-)
20:41 FROGGS brrt++ # :o)
20:46 dalek MoarVM: 2694b49 | brrt++ | src/jit/emit_x64.dasc:
20:46 dalek MoarVM: Fix format type error in JIT logging
20:46 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/2694b494ea
20:46 brrt that should do it, i'd think; i will admit to not testing if clang agrees
21:02 dalek MoarVM: 9f6fecd | brrt++ | src/ (4 files):
21:02 dalek MoarVM: Add MVM_oops() function to panic with backtrace
21:02 dalek MoarVM:
21:02 dalek MoarVM: This allows us to panic while leaving a pretty backtrace for
21:02 dalek MoarVM: debugging. MVM_panic() is better used for situations in which
21:02 dalek MoarVM: we expect memory corruption, but there are still plenty of
21:02 dalek MoarVM: situation where some invariant has been invalidated even
21:02 dalek MoarVM: without memory corruption. We used to throw exceptions, but
21:02 dalek MoarVM: they have the disadvantage that they may be caught and mistaken
21:02 dalek MoarVM: for something else.
21:02 dalek MoarVM:
21:02 dalek MoarVM: This only adds MVM_oops() calls in the JIT, as I've most confidence
21:03 brrt and with that, i'm afk :-)
21:03 brrt left #moarvm
21:16 FROGGS joined #moarvm
21:42 FROGGS joined #moarvm

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