Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2014-07-31

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

All times shown according to UTC.

Time Nick Message
01:12 colomon joined #moarvm
01:50 FROGGS_ joined #moarvm
02:42 jimmyz joined #moarvm
02:42 jimmyz Stage parse      :  38.452 , yeah 1s lower
03:44 ventica joined #moarvm
06:38 sergot hi o/
06:44 brrt joined #moarvm
06:51 brrt \o #moarvm
06:54 sergot hi brrt
06:54 brrt hi sergot
06:54 brrt hows your project going? i'm not often in #perl6 these days, so i don't see much of it
07:02 zakharyas joined #moarvm
07:11 brrt i've an evilly awesome idea on how to implement jumplist, btw
07:11 brrt basically, create a segment containing a bunch of jumps after another
07:11 brrt so jmp label1; jmp label2; jmp label3;
07:12 brrt prefix that with a (local) label of its own
07:15 brrt before that, load the address of that label, and load the jump table index, multiply this by the size of a single jmp instruction
07:16 brrt add this to the start label, jump and presto
07:26 brrt only caveat - what if not all jumps are equal in size?
07:36 moritz then you make them equal in size (by extending smaller ones with no-ops)
07:38 klaas-janstol joined #moarvm
07:40 brrt good point
07:44 brrt but, i can't actually figure that out (what the size of a single instruction will be)
07:44 brrt much fuu
07:47 moritz why ever not?
07:48 brrt because dynasm kindly hides that information
07:49 brrt and it seems that a jump to a nearby target is a smaller than a jump to a far target
07:49 brrt hmm, that doesn't have to be so, though
07:49 * brrt may have a solution for that
07:49 brrt basically, a load-effective-address should be relatively constant in size, i'd expect?
07:49 moritz you could talk to the dynasm folks
07:49 brrt good point too
07:50 moritz maybe they have something for aligned jumps
07:50 moritz (or would welcome patches :-)
07:50 brrt hmm that's not really it, i think
07:51 brrt oh wait i see what you mean
07:51 brrt :-)
07:56 brrt btw, i'm seeing something very interesting in the 'unofficial dynasm documentation'
07:56 brrt "If the presence of such a Lua interpreter cannot be assumed, LuaJIT2's minilua can be built and used to invoke dynasm.lua:"
07:56 brrt ok, /me will be adding that to the refactor-todo-list :-)
07:57 brrt also this: http://corsix.github.io/dynasm-doc/reference.html#_align
08:00 brrt basically, instructions can be aligned to the maximum size necessary, i think
08:01 Ven joined #moarvm
08:09 nwc10 n: say 6.8598e+01 / 7.1820e+01
08:09 camelia niecza v24-109-g48a8de3: OUTPUT«0.95513784461152873␤»
08:09 nwc10 jnthn: whatever you did last night, setting compilation now takes 4.5% less time
08:15 brrt figurring out whatever that maximum size is supposed to be is tricky, though
08:17 brrt i /think/ in all 'practical' examples it'll be 5
08:18 klaas-janstol joined #moarvm
08:19 FROGGS joined #moarvm
08:20 brrt so aligning to 8 bytes /should/ be safe
08:23 brrt 4 bytes for a relative memory address... lets' see if i can make that bigger
08:25 brrt really worst-case, 32 bit displacement gives me 7 bytes
08:25 brrt align 8 should be ok
08:28 brrt the only way to go over that, as far as i can tell, is to have 64 bit absolute displacements, and i'm pretty sure dynasm won't output these
08:29 brrt (those 7 bytes are, as far as i can tell, rex, jump, register nr, offset (4 bytes)
08:33 brrt btw, the case of the broken nqp compilation is getting curioser and curioser
08:40 FROGGS yeah, until it is fixed I suppose
08:43 brrt hmm, found something maybe
08:44 brrt ok, found something, probably
08:44 FROGGS O.o
08:48 dalek MoarVM/jit-moar-ops: 06d54a9 | (Bart Wiegmans)++ | src/jit/graph.c:
08:48 dalek MoarVM/jit-moar-ops: Repr ID is literal, not register
08:48 dalek MoarVM/jit-moar-ops: review: https://github.com/MoarVM/MoarVM/commit/06d54a9dcd
08:48 brrt fixed it :-D
08:50 FROGGS so what is next now?
08:51 FROGGS is the iterator bug still present?
08:51 brrt NEIN NEIN NEIN NEIN NEIN
08:51 brrt iterator bug was really 'oh, i can't really compile and deal with handlers properly' bug
08:52 brrt fixing that, will be a bit complex, because it involves the old 'interpreter uses current bytecode offset as semantically valuable' issue for the JIT
08:53 brrt oh, great news, SEGV
08:53 brrt lets see what ASAN does shall we
08:55 brrt jit log bytecode is wrong
08:55 brrt that's funny
08:55 brrt not nearly as stressful as any of the other bugs
08:55 brrt oh, i apparantly haven't got a file handle
08:56 FROGGS I can send you one :o)
08:56 brrt clang, i hate you now
08:56 brrt i told you not to f*****g optimize
08:56 brrt why are my frame variables gone
08:56 brrt why are they optimized out
08:56 brrt that's not a funny joke
08:58 brrt anyway, there's probably something illegal in the name
08:58 brrt hah hah, :infix</>.bin
09:05 FROGGS why is that illegal?
09:10 brrt it contains a slash, so linux trys to make file in  the directory ./jit-cuuid-$number-infix</
09:10 brrt which doesn't exists, hence a null file pointer, hence a crash
09:10 brrt (why don't you check for a null file pointer? well..... .:-$)
09:11 FROGGS ahhh
09:16 dalek MoarVM/jit-moar-ops: c5f6a4d | (Bart Wiegmans)++ | src/jit/log.c:
09:16 dalek MoarVM/jit-moar-ops: Check for NULL in MVM_jit_log_bytecode
09:16 dalek MoarVM/jit-moar-ops:
09:16 dalek MoarVM/jit-moar-ops: Sometimes, routine names contain special characters,
09:16 dalek MoarVM/jit-moar-ops: such as slashes. Rather than dealing with that, I'll
09:16 dalek MoarVM/jit-moar-ops: just as well not dump that bytecode.
09:16 dalek MoarVM/jit-moar-ops: review: https://github.com/MoarVM/MoarVM/commit/c5f6a4ddb0
09:16 brrt i think i can merge that with moar-jit now
09:16 brrt because all the quick tests look as if they work
09:17 brrt i'm not, by the way, in total agreement with regards to the implmenentation of newlexotic, but i'll see what i can do about that
09:18 dalek Heuristic branch merge: pushed 34 commits to MoarVM/moar-jit by bdw
09:22 brrt ok, bbi3h, i'll try to implement jumplist / jumptable, sp_findmeth and the like
09:23 nwc10 brrt: 7d17cb0498aebe69d5e9b1d870604d2f39b09e90 didn't upset ASAN
09:23 nwc10 will take less than 3 hours to tell you about the new one :-)
09:23 brrt very nice
09:23 brrt i'll see about that then
09:24 * brrt off
09:24 brrt also timotimo++ for so many commits
09:24 brrt left #moarvm
09:47 nwc10 brrt: ASAN still fine
10:05 jnthn brrt++ # bug finding
10:07 FROGGS jnthn: I found a but right now and wonder where to start investigating: https://rt.perl.org/Ticket/Display.html?id=122447
10:07 jnthn what what
10:08 FROGGS in the...
10:08 jnthn What's weird.
10:09 jnthn Though curious it happens consistently on JVM and Moar
10:09 FROGGS I just wonder what SCRef it is trying to serialize
10:10 FROGGS and I dunno how to check
10:11 jnthn Well, it's a reference to an SC
10:11 FROGGS don't you say :P
10:11 jnthn But quite why we have one of those I don't know
10:11 jnthn Well, or why we have one somewhere and try to serialize it
10:12 jnthn You can detect it by looking at ->REPR->ID
10:12 jnthn So I'd maybe just set a conditional breakpoint in the code that adds things to an SC and see what place adds the SCRef
10:15 FROGGS okay
10:20 dalek MoarVM: e68fa51 | (Tobias Leich)++ | src/core/interp.c:
10:20 dalek MoarVM: fix op name in error message
10:20 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/e68fa518ff
10:27 FROGGS hmm, so it seems we add only one SCRef to one of the SC's, and this are two lines of the bt:
10:27 FROGGS at <unknown>:1  (/home/froggs/dev/nqp/install/languages/nqp/lib/QAST.moarvm:deserialization_code:4294967295)
10:27 FROGGS from gen/moar/stage2/QAST.nqp:4476  (/home/froggs/dev/nqp/install/languages/nqp/lib/QAST.moarvm:compile_node:253)
10:28 jnthn Yes, I meant breakpoint in the C code to see if comes from another object, or a lexpad, or whatever.
10:31 FROGGS okay, running now until it hits the break
10:32 FROGGS but I don't know how to check where it comes from
10:32 FROGGS ohh, do you mean by looking at the gdb backtrace?
10:34 FROGGS #0  MVM_sc_set_object at src/6model/sc.c:173
10:34 FROGGS #1  MVM_sc_push_object at src/6model/sc.h:140
10:34 FROGGS #2  write_obj_ref at src/6model/serialization.c:365
10:34 FROGGS #3  write_ref_func at src/6model/serialization.c:628
10:34 FROGGS #4  serialize at src/6model/reprs/P6opaque.c:1087
10:40 jnthn Hm, seems the optimizer lost the interesting stack frames...
10:40 jnthn (between 3 and 4)
10:41 FROGGS here is the bt in full length:
10:41 FROGGS https://gist.github.com/FROGGS/3bde10c30c9fe3c6723b
10:41 jnthn oh wait, I misread
10:42 jnthn OK, it comes from a P6opaque
10:42 FROGGS yeah
10:42 jnthn That means somehow, some object we end up trying to serialize contains an SCRef
10:43 FROGGS and again I'd like to do $obj.VAR.name in C :o)
10:45 FROGGS yeah: p *((MVMObject *)0x7ffff6782d40)->st->REPR shows: name = 0x7ffff7a235b5 "SCRef"
10:46 jnthn You could try finding where it's set by spotting it and dumping a backtrace in bind_attribute
10:47 jnthn You'd have to turn off spesh to make sure it doesn't do away with the bind_attribute calls though
10:47 jnthn We should put it in to a Perl6::World (inherited from HLL::World) instance, for example
10:56 colomon joined #moarvm
11:11 timotimo brrt, *ouch*, the repr id pointed at a random register? yeah, that's bad.
11:14 FROGGS jnthn: we do this: MVM_sc_set_object(tc, sc=0x7f9426e81d40, idx=810, obj=0x7f9426e81d40)
11:15 timotimo but doesn't that just put an object into an sc?
11:15 FROGGS yes, where the obj is the sc itself
11:15 jnthn OK, where does taht happen?
11:15 FROGGS bindattr_o o=0x7f9426e81d40
11:15 FROGGS at <unknown>:1  (/home/froggs/dev/nqp/install/languages/nqp/lib/QASTNode.moarvm:sc:4294967295)
11:15 FROGGS from gen/moar/stage2/QASTNode.nqp:59  (/home/froggs/dev/nqp/install/languages/nqp/lib/QASTNode.moarvm:new:34)
11:15 FROGGS from src/Perl6/Actions.nqp:406  (/home/froggs/dev/nqp/install/languages/nqp/lib/Perl6/Actions.moarvm:comp_unit:1019)
11:16 FROGGS that is a bt called from bindattr_o where the _o has REPR->ID 17
11:16 FROGGS which is our SC
11:18 timotimo oh, that seems weird
11:18 timotimo but i don't know how our scs work internally
11:20 FROGGS so $*W.sc() is exactly at that address
11:21 FROGGS but I don't understand that... we are creating a $compunit..., how can that be on the same memory address as $*W.sc()?
11:22 jnthn Yeah, something is odd there
11:23 jnthn Wait, does that MVM_sc_set_object call happen as part of the bindattr (due to tripping an SC write barrier)? Or much, much later?
11:25 timotimo oh, the write barrier would be a sensible thing to do
11:25 FROGGS I see two bindattr_o, one showing Perl6::Actions, the other one QAST.compile_node (identical to the sc_set_object)
11:26 FROGGS the P6::A comes first of course
11:26 jnthn Ah
11:26 FROGGS the latter and the sc_set_obj could be following each, but I cant tell
11:26 jnthn I was expecting a third one...
11:27 jnthn Unless somehow Perl6::World is making it into the SC...
11:27 FROGGS there another one before Perl6::A that shows a different mem addres
11:27 FROGGS s
11:27 FROGGS coming from
11:27 FROGGS from gen/moar/stage2/NQPCORE.setting:514  (/home/froggs/dev/nqp/install/languages/nqp/lib/NQPCORE.setting.moarvm:BUILDALL:61)
11:27 FROGGS from gen/moar/stage2/NQPCORE.setting:499  (/home/froggs/dev/nqp/install/languages/nqp/lib/NQPCORE.setting.moarvm:bless:17)
11:27 FROGGS from gen/moar/stage2/NQPCORE.setting:560  (/home/froggs/dev/nqp/install/languages/nqp/lib/NQPCORE.setting.moarvm:new:10)
11:27 FROGGS from src/Perl6/Grammar.nqp:341  (/home/froggs/dev/nqp/install/languages/nqp/lib/Perl6/Grammar.moarvm:TOP:499)
11:28 FROGGS which is about creating our $*W
12:14 klaas-janstol joined #moarvm
12:18 brrt joined #moarvm
12:18 brrt \o
12:19 jnthn o/ brrt
12:19 brrt we have no known bugs in the JIT :-)
12:20 moritz does that mean somebody fixed the iter weirdness?
12:20 moritz \o/
12:20 nwc10 write more tests
12:22 brrt jnthn++ found that the weirndess was caused by the frame having handlers, and /me not having implemented the code to deal with that
12:22 brrt it is quite complex, though, so i'm trying not to feel bad
12:22 FROGGS jnthn: all three bindattr_o bind '$!sc'
12:25 brother joined #moarvm
12:25 brrt hmm jnthn, i have four things on my immediate to do list
12:25 FROGGS okay, this first sc is $*W, then we bind $*W.sc() to probably $compunit, and then we bind the same $*W.sc() to something else in QAST.compile_node
12:25 brrt or rather, yesterdays todo list
12:25 FROGGS and the third seems to explode
12:26 brrt sp_findmeth, the jumplist thingy, proper implementation of throwish and handlers, and non-speshed args
12:26 brrt oh, and extops of course
12:27 jnthn OK :)
12:28 jnthn Well, all matter. Given you just had some frustrating days of debugging, it may be nice to pick some that shouldn't be too horrible to do.
12:28 brrt handlers seem like the most complex of these
12:28 jnthn Right.
12:28 brrt jumplist is going to be fun, but i don't know if there are any non-regex tests
12:28 jnthn No, it shows up entirely in regexes.
12:29 jnthn So far, at least.
12:29 jnthn It tends to show up near the *end* of regexes too
12:29 jnthn Meaning that if you're getting that far you'll likely get the rest of the way through the regex code.
12:30 FROGGS this is the '$!sc' #3:
12:30 FROGGS $block.push(self.deserialization_code($cu.sc(), $cu.code_ref_blocks(),
12:30 FROGGS $cu.repo_conflict_resolver()));
12:30 brrt ok, but that's still pretty awesome
12:30 * brrt is collecting the core.setting jitlog
12:47 FROGGS jnthn: that means that I still don't know how the sc gets into its own attribute slot, right?
12:47 jnthn FROGGS: Yeah, think something's missing still
12:56 brrt jnthn: jumplist nodes are always followed by a set of goto statements, right?
12:56 brrt i.e. i can consume a jumplist + gotos as if it were a single node
12:58 brrt its current implementation seems to be: jump 6 * x bytes, after which we land on a goto, after which the goto will take us where we want to be
12:59 jnthn brrt: Correct, and there's a special case for non-match which I froget.
12:59 jnthn brrt: The bytecode verifier ensures that jumplist is followed by enough gotos
13:00 * brrt checks it out, and would easily forget it
13:00 jnthn brrt: So basically you can assume that's what you'll always have.
13:00 brrt ok
13:03 brrt the negative or greater-than-number-of-labels case, that... is inelegant
13:06 jnthn huh?
13:06 jnthn It's just saying "skip over all the gotos"
13:06 brrt oh....
13:06 brrt /pfew/
13:07 brrt that is implementable
13:07 brrt i read that wrong, i guess
13:07 jnthn /* skip the entire goto list block */
13:07 jnthn :)
13:10 brrt :-)
13:10 FROGGS jnthn: compiled perl6-m with optimization turned off fails with: getlex: outer index out of range
13:14 timotimo i wonder where we have native nums we use in the setting compilation process
13:14 jnthn "optimization"?
13:14 timotimo because eq_n is somewhat common (28 times)
13:14 FROGGS jnthn: I changed the Makefile so it reads: --optimize=off
13:14 FROGGS it fails building RESTRICTED.setting.moarvm then fwiw
13:14 carlin_ joined #moarvm
13:14 lizmat_ joined #moarvm
13:14 jnthn timotimo: NQP defaults to floating point for numbers in the absence of "int" decls
13:15 tadzik joined #moarvm
13:15 odc joined #moarvm
13:16 TimToady joined #moarvm
13:16 brrt don't the goto's all end a basic block?
13:16 timotimo oh, i forgot about that
13:16 xiaomiao joined #moarvm
13:19 brrt nope, is handled as a special case
13:19 jnthn Yes
13:19 jnthn Every goto is in its own BB
13:20 brrt hmm ok
13:20 brrt well, then, i'll have to walk bb's then :-)
13:28 FROGGS ohh dear... now I run into a spesh bug again >.<
13:29 FROGGS "postcircumfix:<{ }> binding not defined for type Hash" at rakudo/src/core/CompUnitRepo/Local/File.pm:62: $potentials{$root}{$ext} := \($file, :name($root) );
13:30 lizmat :-(
13:31 nwc10 Every goto is sacred? https://www.youtube.com/watch?v=fUspLVStPbk
13:31 nwc10 [not actually a rickroll, but maybe it should have been :-)]
13:32 jnthn FROGGS: Do you know it's a spesh bug?
13:32 jnthn I thought you already had this exact one before.
13:34 FROGGS[mobile] joined #moarvm
13:36 brrt every goto is sacred
13:37 brrt oh what a horrible scene that is
13:38 FROGGS[mobile] jnthn: I had this before and it vanishes when spesh is disabled
13:39 FROGGS[mobile] it shows up know when I require a file from within v5
13:40 nwc10 a rickroll looks like this: https://www.youtube.com/watch?v=dQw4w9WgXcQ
13:40 brrt the horror of overpopulation, that is; thank god for demographic transition
13:44 jnthn FROGGS[mobile]: Yeah, but I thought I'd already fixed it :/
13:47 * brrt bbiab, errands &
14:04 FROGGS[mobile] jnthn: yes, that's why I cry
14:05 brrt joined #moarvm
14:16 brrt ooh, it blows up swiftly
14:19 timotimo that's a good sign :)
14:19 brrt i suppose it is
14:27 timotimo "it" refers to jumplists?
14:29 brrt yes
14:29 brrt i suspect i jumped a little too far
14:30 timotimo if you think you're not progressing with jumplist, try something easier, like not_I, ne_s, lt/gt/le/ge_s and _n, ... :P
14:31 timotimo indexat, indexnat :)
14:31 timotimo well, you have the list, too
14:31 timotimo er, i meant not_i actually
14:32 brrt but jumplist is fun :-)
14:32 jnthn And useful :)
14:33 timotimo fair enough :)
14:33 timotimo how far are we off from turning sufficiently simple given/when or if chains into jumplists? :P
14:33 timotimo actually ... i don't think it'd even really be worth it at all
14:33 timotimo in the if chain case
14:48 jnthn timotimo: I think that transform would go in the Perl 6 optimizer, and I don't see it as especially trivial
14:49 jnthn Also I don't know how much real code has it :)
14:49 jnthn Forest fire kinda does...
15:01 brrt ehm, the regex graphs ends with a goto? wtf? that isn't right
15:03 jnthn No, it's not right :)
15:03 jnthn The jumplist is one of the last things
15:03 jnthn But not *the* last thing
15:04 jnthn The fallthrogh does self.'!cursor_fail'() and return self, iirc
15:05 brrt there ought to be a return, at the very least
15:05 cognome joined #moarvm
15:05 jnthn yeah
15:06 jnthn You've not nomming too many blocks as the goto blocks?
15:43 oetiker left #moarvm
16:21 brrt joined #moarvm
16:37 ventica joined #moarvm
17:14 Ven joined #moarvm
17:52 brrt joined #moarvm
17:54 brrt no, it appears not, i thought that might be the case but the spesh log agrees with the jit log
18:12 cognome joined #moarvm
18:12 cognominal joined #moarvm
18:35 Ven joined #moarvm
18:57 brrt aha, emit jump to label -1
18:57 brrt very interesting
18:57 brrt oh wait, that's nothing
18:57 brrt grrr
18:58 jnthn .oO( If the -1 is the root of the problem, it must be a complex problem... )
18:58 [Coke] jnthn: you're a dirty Rat.
19:01 brrt :-)
19:01 * brrt enjoys the punning in #moarvm
19:20 TimToady i do two.
19:21 TimToady 2i or not 2i, that is the question...
19:22 brrt but, it does seem at least that there's a 'negative label' assigned
19:24 TimToady that doesn't square with y jnthn abcissas over 0...
19:24 TimToady -1 is obviously under 0
19:25 TimToady *abscissas
19:26 TimToady in any case, it's in-ordinate...
19:28 brrt :-)
19:28 brrt good news all, php has a spec :-)
19:28 brrt now we can implement php for moar
19:29 TimToady well, but they won't come unless we de-emphasize the link with Perl 6...
19:30 TimToady really, though, I'd think it would be much better to give them a refactoring translator to Perl 6...
19:35 brrt (how cool is it that we can nearly jit compile regexes, btw)
19:35 jnthn Very :)
19:36 jnthn OK, I'm done with $dayjob things until Monday :)
19:36 jnthn Going to take a stroll, then will look at Rakudo/Moar things. :)
19:39 brrt see you then
19:39 * brrt was going to swim but it's just a bit too dark outside
19:42 btyler brrt: that is extremely cool! I didn't realize that regexes were in scope for your JIT work...very exciting
19:43 brrt neither did i, but the total lack of any regex-specific code in moarvm should have aroused my suspicion
19:43 brrt and timotimo++ implemented most of the ops necessary, so that only the asm-level ops were necessary
19:46 timotimo aye, we compile regex to "just" moarvm bytecode
19:47 timotimo we just have a few ops that are especially useful in regexes as compared to everyday code, like "findcclass" and "findnotcclass"
19:47 TimToady not having a separate regex engine was something I insisted on from the very start
19:48 TimToady the first time I mentioned it in a design meeting, I got blank looks all around
19:48 timotimo well, to be honest, the NFA thing is kind of separate
19:48 timotimo but that part is not something you'd need to re-implement in jitted form
19:49 timotimo it's quite a monolithic blob that you can just call through its interface and be fine
19:49 Ven joined #moarvm
19:51 * TimToady had way too much experience with inferior regex runloops in Perl 5
19:52 TimToady it wasn't a mistake I cared to repeat
19:53 timotimo how come we ended up with inferior runloops in parrot?
19:53 TimToady alas, parrot kind of fell into nested runloops while I wasn't paying attention
19:53 timotimo ah
19:54 TimToady taking a year off for various stomach surgeries is kind of distracting that way...
19:55 timotimo oh my :\
19:56 TimToady well, didn't take it off completely, but it was a year before my brane was fully up to snuff again
19:57 TimToady poor nutrition and multiple anesthesias will do that to you
20:00 timotimo i can only imagine
20:01 raiph joined #moarvm
20:05 TimToady on top of which, they told me in no uncertain terms that I was the language designer, not the implementor, and they didn't want the internals of parrot to turn out like Perl 5
20:05 TimToady so they ended up making the same mistakes differently, instead of making different mistakes
20:05 TimToady well, they made some of those too, I suppose... :)
20:06 TimToady required nap is required &
20:20 masak back when I learned about the "inferior runloop", I couldn't understand why when I Googled the term, I only got Parrot hits.
20:20 masak now I know.
20:21 brrt is parrot the only thing that ever did that?
20:23 * jnthn back
20:24 jnthn MoarVM does have some operations in its opset that are there with making regex interpretation/compilation efficient.
20:24 jnthn *with the goal of
20:24 jnthn But they're part of the same interpreter as everything else.
20:36 Ven joined #moarvm
20:42 jnthn Urgh, my problem last night is a spesh bug...
20:43 jnthn And it *looks* like it might be in optimizing isfalse
20:45 jnthn oh...yeah.
20:45 jnthn timotimo: About?
20:49 * timotimo -> Help -> About
20:52 jnthn timotimo: Well, think I found it... https://gist.github.com/jnthn/d202be34d80ad085cc71
20:55 jnthn That patch helps, anyways.
21:06 timotimo that fixes what exactly?
21:06 jnthn isfalse r0, r1
21:06 jnthn if r0 goto foo
21:06 jnthn r1 was something with boolspec meaning we could lower it to isconcrete
21:07 jnthn So it did that
21:07 jnthn Then it said "oh, but isconcrete can be optimzied maybe"
21:07 jnthn So that got optimized into an iconst op
21:07 jnthn Then it added the not_i there and assigned back to the same reg (naughty)
21:08 jnthn But the iconst op isconcrete had put there had a known value
21:08 jnthn And the not_i was re-using the fact without flipping the known value.
21:08 jnthn Then the if_i got optimized into a branch to the wrong place. :P
21:09 jnthn While I'm quite please to see an isfalse/if get optimized into a goto, it's helpful if it goto's the correct branch :)
21:09 jnthn *pleased
21:09 timotimo oh damn!
21:09 timotimo that was a pretty nasty combination of things
21:10 timotimo sorry about that
21:10 jnthn np
21:10 timotimo did that cause the Nil thing for xor?
21:10 jnthn No idea
21:10 timotimo i don't see a reason to not commit that, it sounds quite sane.
21:10 jnthn But it did cause CORE.setting compilation to explode with my patch that improves NQP optimization.
21:11 jnthn Basically, regexes that called back into NQP code poisoned.
21:11 jnthn I've changed that and now it can lower more lexicals and - even better - flatten away many nested blocks
21:12 jnthn Which is enough to shave almost another second off stage parse here.
21:12 timotimo yus!
21:12 jnthn however, something bizzare happens.
21:12 jnthn Stage optimize   : WARNINGS:
21:12 jnthn Useless use of "," in expression "my %m =\r\n      '$*'  => '^^ and $$',\r\n      '$\"'  => '.join() method',\r\n      '$$'  => '$*PID',\r\n      '$('
21:12 timotimo dear lord. rakudo-jvm is still going at i.
21:12 jnthn ...
21:13 jnthn That's quite clearly not useless...
21:13 timotimo it's doing benchmark 31 of 63 now
21:13 timotimo is , marked as pure or something?
21:14 jnthn yeah
21:14 jnthn But it's in an assignment which sure ain't
21:15 timotimo .. right
21:15 timotimo well, can you reproduce it with only that little statement?
21:15 timotimo and get the --target=optimize and --target=ast?
21:15 jnthn WEll, it's in the entirelty of CORE.setting
21:15 timotimo of course it is %)
21:15 jnthn but I get spectest fails too that will give me more clues
21:15 timotimo aye
21:15 FROGGS lol, --target=ast on the setting :P
21:16 timotimo is jit-moar-ops being blocked from being merged ATM?
21:17 brrt no, jit-moar-ops has been merge
21:17 brrt d
21:17 brrt :-)
21:18 brrt jumplist is blocking-on-merged because? the code isn't even ever touched
21:18 timotimo oh, it has been?
21:18 timotimo cool :)
21:19 timotimo i'm glad my contributions were warmly accepted into the main jit development branch
21:20 timotimo jnthn: clearly, the way it was before is wrong, so even if your patch introduces spectest failures, the previous state *has* to have been worse %)
21:20 timotimo perhaps in much subtler ways
21:21 timotimo er, wait
21:21 timotimo that problem in the setting and spectests is not from fixing the not_i thing, it's from making the nqp optimizer in-line stuff more heavily
21:22 jnthn Right.
21:22 jnthn Oh, I know that.
21:22 timotimo will you commit & push the patch for isfalse?
21:25 * brrt is not gaining any insight from walking through the breaking frame
21:26 jnthn oh wtf, it's compiling a list assignment as an item assignment
21:26 jnthn timotimo: Can do
21:26 jnthn Just trying to figure out the other thing...
21:26 Ven Error while compiling op bind: QAST::Block with cuid cuid_532_1406661053.31266 has not appeared
21:26 Ven uuuh.
21:27 Ven m: say so 'foobar' ~~ / foo ( A B C ) ** 0 bar /;
21:27 camelia rakudo-moar ccda7d: OUTPUT«===SORRY!===␤Error while compiling op bind: QAST::Block with cuid cuid_1_1406842041.65097 has not appeared␤»
21:28 dalek MoarVM: b83a206 | jnthn++ | src/spesh/optimize.c:
21:28 dalek MoarVM: Update facts during isfalse optimization.
21:28 dalek MoarVM:
21:28 dalek MoarVM: We got the facts out of sync with the not_i insertion, meaning that a
21:28 dalek MoarVM: wrong branch could then result later.
21:28 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/b83a206169
21:30 timotimo benchmark 37 out of 63 ...
21:32 jnthn Arrgh
21:37 timotimo good thing i started it on my desktop before i left home
21:37 timotimo rather than when i arrived here
21:37 timotimo nqp-jvm is still ahead of us, though
21:37 timotimo i may ctrl-c that, though
21:44 dalek MoarVM: b12cccd | jnthn++ | src/core/op (2 files):
21:44 dalek MoarVM: Cannot inline [get|bind]lexdyn.
21:44 dalek MoarVM:
21:44 dalek MoarVM: They do a tc->cur_frame->caller, which of course will look different
21:44 dalek MoarVM: if we were to inline them.
21:44 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/b12cccdee4
21:51 brrt ugh, getwhat has an operands error
21:51 brrt such dumb
21:51 FROGGS jnthn: your last patch might fix what I've seen earlier
21:52 jnthn FROGGS: Yeah, wroth a try
21:52 jnthn *worth
21:52 jnthn We do have a problem with dynamics and spesh still though
21:52 jnthn They're looked up by name
21:53 jnthn And when we're searching for $*FOO we don't take into account lexicals declared in things we've inlined.
21:53 FROGGS ohh
21:54 jnthn Which I can fix quite easily for interpreted things.
21:54 jnthn Because I can use the current bytecode location/pointer to know where we are
21:54 jnthn And then consider the appropriate inlines.
21:54 jnthn But...JITted frames with inlines present more of a challenge.
21:55 jnthn But I guess deopt_all must already handle this...
21:55 jnthn brrt: Lemme know when I can borrow your brane for a moment :)
21:55 brrt borrow away
21:55 brrt but my bran is in the kitchen
21:57 * brrt hasn't read all the discussion yet
21:58 jnthn brrt: (How) is the deopt_all case of uninlining handled wrt JIT?
21:58 brrt i haven't seen that yet
21:58 jnthn Or deopt_all in general I guess
21:58 brrt as far as i know, only rebless does deopt_all
21:58 jnthn Right
21:58 jnthn But it has far-reaching consequences
21:58 jnthn It deopts in place all frames down the stack
21:58 brrt hmmmm
21:59 jnthn When the JIT invokes something, what information does it keep around?
21:59 brrt it uses a pointer called jit_entry_label
21:59 jnthn OK, that's used when we return?
21:59 brrt this is a direct address into the bytecode of the next instruction
21:59 brrt so it's the return_address of the JIT
22:00 jnthn Where bytecode = JITted machine code, yes?
22:00 brrt yes
22:00 jnthn OK
22:00 brrt yes
22:00 jnthn That's not going to be quite enough for deopt_all I suspect
22:00 brrt no, but here's the thing more or less
22:01 brrt for regular invoke ops, there' always a mapping between basic block -> jit entry label
22:01 brrt regular invokes use so-called dynamic labels, but these aren't all that dynamic, they are 'linked' at compile time
22:01 brrt for invokish ops, which do not need to end at basic block boundaries, i use the address of local labels, and these are computed at runtime
22:02 brrt what you'd probably need - i assume - is to map the jit entry labels to the original moar bytecode somehow
22:02 jnthn Yeah
22:03 jnthn Well
22:03 jnthn What we actually need is to know is what inline we're inside, if any.
22:03 brrt if you can do that, you're golden; however for invokish ops i can't guarantee such a mapping, /unless/ this position can be computed at spesh-codegen time (or at annotation time)
22:04 brrt hmmm
22:04 jnthn Well, position can't, but inline index trivially can.
22:04 brrt yeah
22:04 jnthn (There's annotations)
22:05 brrt well, i can in principle add bookkeeping to the JIT so some kind of inlining index is updated whenever we move a boundary
22:05 jnthn Yeah
22:05 jnthn We probably need to do that
22:05 jnthn It ties into the issue I'm about to fix now
22:05 jnthn But given the machinary isn't there for the (more common) deopt_all goes, I'm not gonig to worry over it hugely yet
22:06 jnthn But at present, deopt_all and a rare interaction between inlining and dynvars are going to be JIT issues.
22:06 jnthn Just so you have them in mind when debugging.
22:08 brrt ok, but i don't think i do these yet
22:08 brrt i'm perhaps a bit overly cautious
22:08 brrt oh, weird, 'invoke instruction  isn't last of basic block or is last of graph', let's check that out
22:08 jnthn They're both sufficiently action-at-a-distance you can be easily bitten
22:09 * brrt nods with feeling
22:11 brrt it cautiously appears my evil jumplist scheme is working
22:13 jnthn :)
22:13 jnthn Dynvar lookups are sufficiently action-at-a-distance that I've just got bitten on the interaction of them with inlining.
22:15 TimToady btw, the Perl 4 compiler did the jumplist optimization on if/elsif/else, and in fact also did it on the first characters of strings if the matchers in each condition were anchored to ^
22:16 jnthn o.O
22:17 TimToady in fact, it didn't even have to be if/elseif/else, it did it on any exclusive guards
22:17 TimToady well, if there were more than three or so
22:20 TimToady in fact, I think it even handled character sets on the first character match (all ASCII semantics, of course)
22:20 brrt yep, there's a fastinvoke that's not the end of bb
22:20 brrt i'll get to that later
22:23 brrt (stage parse took even longer than normal now :-o)
22:23 brrt oh wait
22:23 brrt i'm logging spesh and jit logs
22:25 jnthn Yes, spesh_log alone can add a LOT
22:25 brrt still 53s :-o
22:25 brrt :-(
22:26 dalek MoarVM/moar-jit: 7eb1b80 | (Bart Wiegmans)++ | src/jit/emit_x64.dasc:
22:26 dalek MoarVM/moar-jit: Fix bug in getwhat/getwho etc
22:26 dalek MoarVM/moar-jit: review: https://github.com/MoarVM/MoarVM/commit/7eb1b80f54
22:26 dalek MoarVM/moar-jit: 681b4ec | (Bart Wiegmans)++ | src/ (8 files):
22:26 dalek MoarVM/moar-jit: Add jumplist support.
22:26 dalek MoarVM/moar-jit:
22:26 dalek MoarVM/moar-jit: This is necessary for the compilation of most regexes.
22:26 dalek MoarVM/moar-jit: review: https://github.com/MoarVM/MoarVM/commit/681b4ec44d
22:27 brrt oh, disabling jit makes no differense / 0.2 s slower
22:27 brrt so
22:27 brrt that's not it, at least
22:27 brrt maybe computer is just slow today
22:28 brrt anyway, that was jumplist, hope you enjoy, will be here tomorrow for more epic bugfixing and maybe actually implementing some functionality
22:28 brrt /sarcasm-off
22:28 brrt :-)
22:28 jnthn :-)
22:29 jnthn I'll give JIT a try tonight if I fix this other thing, or tomorrow morning. :)
22:29 brrt have fun :-)
22:29 jnthn :)
22:29 brrt sleep &
22:29 jnthn 'night o/
22:29 brrt left #moarvm
22:43 jnthn Ah good, spectest is looking better with the fix
22:43 jnthn Made dynvar lookup more costly again to fix it though.
22:43 jnthn Really gonna have to do something about that...
22:46 dalek MoarVM: 1fd42e6 | jnthn++ | src/core/frame.c:
22:46 dalek MoarVM: Account for inlining in dynlex lookup.
22:46 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/1fd42e6845
22:47 TimToady well, we have ::= to indicate a readonly dynvar, which you can copy the value down instead of the container
22:48 TimToady m: my $x ::= 42; $x = 43
22:48 camelia rakudo-moar 89c8e4: OUTPUT«Cannot assign to an immutable value␤  in block  at /tmp/X85viNoPuo:1␤␤»
22:48 jnthn You can't copy the container down in the other case 'cus you might re-bind
22:49 TimToady maybe we can call that erroneous
22:49 jnthn Well, the real time-consuming bit is that every time you do $*FOO, we go looking down the call stack to find it.
22:49 TimToady m: my $a = 42; my $x ::= $a; $x = 43
22:49 camelia rakudo-moar 89c8e4: ( no output )
22:49 jnthn Every. Single. Time.
22:49 jnthn Just to figure out which frame declares it.
22:49 TimToady yes, that's why it's always been envisioned that it would be cached locally
22:50 TimToady like env vars are, at least in unix
22:50 jnthn Sure. I've just been scribbling out a cache mechanism for it here. :)
22:50 TimToady it would appear that ::= is just doing := currently
22:50 TimToady not defaulting $x to readonly
22:51 jnthn Yeah, we're cheating there at the moment.
22:51 TimToady hmm
22:51 jnthn How does that work anyway? Just decont before binding?
22:51 TimToady m: constant $*foo = 42;
22:51 camelia rakudo-moar 89c8e4: OUTPUT«[31m===[0mSORRY![31m===[0m Error while compiling /tmp/AP0smLPZaQ␤Twigil-Variable constants not yet implemented. Sorry. ␤at /tmp/AP0smLPZaQ:1␤------> [32mconstant $*foo = 42[33m⏏[31m;[0m␤    expecting any of:␤        postfix␤»
22:51 jnthn Well, can't be decont if it's a $ sigil otherwise we'll screw up flattening
22:51 TimToady ::= is supposed to work exactly as it does in siggies
22:51 jnthn Has to work like param...right. :)
22:52 jnthn And I already dealt with that issue there.
22:52 TimToady so same deal, basically
22:52 jnthn In my last profile of CORE.setting compilation, before the latest opt I have here, 1.8% of the time was on dynvar lookups.
22:52 jnthn Which already sounds bad enough
22:52 jnthn Except I suspect their cache consequences may be quite horrific too if you need to go deep to find the thing.
22:53 TimToady well, if something's cached halfway, you can stop there
22:53 jnthn (as in, CPU cache)
22:53 jnthn I'm thinking of just keeping a cache per thread
22:53 TimToady how bout just a local
22:53 TimToady don't make a big datastructure
22:53 jnthn And marking frames we cache things from
22:54 jnthn And when we return from those we just invalidate the cache entry.
22:54 TimToady returning throws away the locals
22:54 jnthn A local where, exactly?
22:55 jnthn The problem isn't typically that we look them up in loops, at least not for the compiler
22:55 TimToady I mean a lexical; just install a my $*foo = caller's $*foo anywhere you think you need it
22:55 jnthn Oh, I was thinking of having the VM cache it
22:55 TimToady and it already will be found by the current lookup
22:55 TimToady it'll just be closer
22:55 timotimo i'm now at benchmark 58 of 63
22:55 jnthn That trick will show up if we introspect, though.
22:56 TimToady I don't think that matters much, and we can mark fake ones somehow
22:56 jnthn Still means we need smarts on where to put them.
22:57 jnthn And will also get re-binding wrong.
22:57 * TimToady is quite willing to forbid rebinding
22:57 TimToady and, offhand, you can cache it where you noticed it's being used
22:58 TimToady or just outside that, if it's a loop
22:58 jnthn I'm not convinced this solution wins us anything over the VM-level caching I'm proposing.
22:58 jnthn We'll get most of them down to a single hash lookup
22:58 TimToady automatic cleanup
22:58 jnthn After the first time we look for it after declaration
22:58 jnthn True.
22:59 TimToady it's how I pictured them from the start, anyway
22:59 jnthn Said unwind stuff is in exactly one place, though...
22:59 timotimo should i backlog the recent hours?
22:59 TimToady well, I like how env vars just get copied into the current process
23:00 TimToady and exit() cleans them up real quick :)
23:00 jnthn Sure. But to consider a concrete use case...
23:00 jnthn $*ACTIONS
23:00 jnthn It's declared and accessed in Cursor
23:01 jnthn And barely mentioned in Perl6::Grammar
23:01 jnthn $*W is used all the time in Perl6::Actions and never mentioend there
23:01 jnthn It's really hard to insert the copies.
23:01 jnthn In an effective way, I mean. Or to know what copies to insert.
23:01 TimToady nodnod
23:02 jnthn uh, never mentioned there wasn't quite right...
23:02 jnthn But it's hard to see how caching it at that level helps a lot when there's all the grammar frames below.
23:02 TimToady reserve one slot per frame for a cache maybe, and just cache it halfway, if unoccupied?
23:03 jnthn Hm, could work.
23:03 TimToady so populate it stochastically?  maybe occasionally remove them probabalistically to make room for mode shifts
23:04 jnthn Well, if the current frame you're on doesn't have a space for it, you can always look one down.
23:04 TimToady various ways that it could improve things on average without too much cost
23:04 TimToady yes, and if both of those are the same, steal one
23:09 TimToady after all, they're *dynamic* :)

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