Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2015-05-05

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

All times shown according to UTC.

Time Nick Message
00:31 timotimo if i merge jit_devirtualize_reprops, we'll be able to throw out a roadmap entry that's targeted at 2015.06
00:32 timotimo and if i do it now-ish, we'll have plenty of testing until the release
00:33 timotimo however, right now things are already shaky due to the recent CUR changes and there's probably a bit of hash order reliance hidden in the ecosystem
01:55 synbot6 joined #moarvm
01:58 synbot6 joined #moarvm
02:47 synbot6 joined #moarvm
03:03 harrow joined #moarvm
06:54 jepeway joined #moarvm
06:57 zakharyas joined #moarvm
07:26 Ven_ joined #moarvm
07:29 brrt joined #moarvm
07:34 brrt timotimo: i'm for it
07:34 timotimo oh hey brrt
07:34 brrt i'll run a spectest asap
07:34 brrt oh hi :-)
07:34 brrt just for my clarity
07:34 brrt which branch is it you want to merge
07:37 timotimo jit_devirtualize_reprops_3
07:37 timotimo i might rebase it before i attempt a merge
07:50 brrt try one without a number
07:50 brrt :-P
07:53 timotimo ?
08:07 brrt well, imho there's no reason to tag numbers to branches
08:07 brrt especially if you progress linearly on them
08:15 timotimo i rebased 3 times
08:15 timotimo er
08:15 timotimo 2 times
08:16 brrt ah well
08:16 brrt i see
08:27 Ven_ joined #moarvm
08:41 timotimo implicit declaration of function ‘pthread_yield’ - has this always been there?
08:41 jnthn kinda
08:42 jnthn Last time I tried to fix it, I broke the build on various paltforms. We did have a patch recently that refactored it.
08:42 timotimo oh my
08:42 timotimo i don't remember having seen that. but okay
08:43 jnthn But yeah, unless you really are sure how to fix it/test it on a few platforms, the warning is better than a busted build.
09:19 dalek joined #moarvm
09:53 harrow joined #moarvm
10:13 harrow joined #moarvm
10:14 Ven_ joined #moarvm
10:54 Ven_ joined #moarvm
11:21 harrow joined #moarvm
11:29 brrt joined #moarvm
11:40 harrow joined #moarvm
11:44 rurban joined #moarvm
12:14 ggoebel joined #moarvm
12:26 harrow joined #moarvm
12:45 harrow joined #moarvm
13:09 dalek MoarVM/jsoff: 002bd16 | FROGGS++ | / (10 files):
13:09 dalek MoarVM/jsoff: foo
13:09 dalek MoarVM/jsoff: review: https://github.com/MoarVM/MoarVM/commit/002bd16304
13:09 dalek MoarVM/jsoff: be79531 | FROGGS++ | src/ (3 files):
13:09 dalek MoarVM/jsoff: sandbox: attempt to implement scdisclaim op
13:09 dalek MoarVM/jsoff: review: https://github.com/MoarVM/MoarVM/commit/be795316ac
13:19 brrt what, why
13:21 lizmat to be able to precomp an arbitraty data structure
13:21 lizmat perhaps ?
13:22 brrt hmm ok
14:04 jnthn FROGGS: Looks about right, but please put it in a function, not in interp.c ;)
14:04 FROGGS jnthn: yes yes, it is just something to play with
14:05 jnthn *nod*
14:05 FROGGS jnthn: funny is, $a = deserialize(); $a.push(1); serialize($a) breaks while .unshift there works
14:05 jnthn Did you have to disable lazy des, 'cus the code you wrote looks like it should work out...
14:06 jnthn o.O
14:06 jnthn I wonder if you're not clearing the SC entirely?
14:06 FROGGS I disabled it
14:06 FROGGS I think I do, from looking at the debug output
14:06 jnthn See if an SC WB is hit on push?
14:07 FROGGS how do I do that?
14:07 FROGGS timotimo++ suggested that too
14:08 harrow joined #moarvm
14:09 jnthn I'd just put a breakpoint (or debug code) in the sc.c function that is called if it is.
14:10 FROGGS MVM_sc_wb_hit_obj?
14:12 jnthn Yes
14:12 FROGGS well, I hit the same amount of WBs for push and unshift it seems
14:16 jnthn hm
14:22 FROGGS jnthn: I also added test files to rakudo/jsoff
14:22 FROGGS ser.pl and Ser.pm
14:23 FROGGS I test it as: unlink TEST_FILE; perl6 ser.pl; perl6 ser.pl; perl6 ser.pl
14:23 tadzik :D
14:24 tadzik ser is still there
14:24 FROGGS it explodes by that time when using push in ser.pl
14:24 FROGGS still?
14:24 timotimo .o( i haven't seen sergot in a while, have i? )
14:24 tadzik I think it started as emmentallers 'sergenerator.pl' or somtehing
14:24 tadzik ser being polish for cheese
14:24 FROGGS haha
14:25 tadzik we can now invent some fancy acronym for ser and pretend it was about testing all along
14:26 Ven_ joined #moarvm
14:28 FROGGS walk &
14:59 [Coke] "eating your own cheese"
15:23 tadzik yum
16:13 timotimo i think i want the spesh log to output a line number annotation for the first instruction in every BB if it can
16:17 timotimo hm, i'll probably have to go through the deopt table
16:19 JimmyZ_ joined #moarvm
16:21 timotimo i'd prefer only putting the line number annotations in if dumping is asked for, but it seems like i'd best put them in right at the beginning when the spesh graph is constructed from the original byte code
16:22 resr_ joined #moarvm
16:31 timotimo hurm. in reify, "while $!rest && (nqp::elems($rpa) < $count)' gets a full call into &infix:«<» generated >_<
16:31 timotimo even though $count is an int declared variable
16:31 timotimo and that is where the 5.759.092 IntLexRef objects get created in my benchmark
16:31 lizmat perhaps a nqp::islt_i is in order ?
16:32 timotimo nqp: say(nqp::islt_i(5, 10));
16:32 timotimo :o
16:32 timotimo did i just kill camelia?
16:32 lizmat m: use nqp; say(nqp::islt_i(5, 10));
16:32 timotimo wait for 'er to come back first, will ya? :S
16:32 lizmat hehe
16:33 timotimo that would work, but i'm worried about this not code-gen-ing properly ... but i think it's on jnthn's list of known things
16:33 camelia joined #moarvm
16:33 lizmat m: use nqp; say(nqp::islt_i(5, 10));
16:33 timotimo something like "the code-gen is really proud it could figure out to make an intlexref, so it ends up making a call to &infix«<» because there's an object there now"
16:34 timotimo this is part of the thing i'm struggling with; making localref and local accessible as local and localref respectively
16:34 camelia rakudo-moar bf8aaa: OUTPUT«1␤»
16:37 timotimo i'm not really +1 to changing the < to the islt_i
16:37 timotimo i'd rather our code gen does it automatically (again)
16:38 lizmat fine by me...  :-)
16:38 lizmat when that happens, we can get rid of a lot of nqp:: code in various places  :-)
16:38 timotimo mhm
16:39 timotimo i'm not saying the core setting has to be pretty, but it doesn't have to be more obfuscated than necessary
16:41 vendethiel joined #moarvm
16:44 jnthn Maybe it doesn't figure the nqp::elems gives an int...
16:44 timotimo but we've tried to make that work properly like 10 times already?
16:46 jnthn In NQP maybe :)
16:47 * jnthn doesn't remember especially working on that in Rakudo
16:59 FROGGS[mobile] joined #moarvm
17:09 timotimo i'm now in front of a computer again and can look into the nqp::elems thing
17:14 vendethiel joined #moarvm
17:33 camelia joined #moarvm
17:36 camelia joined #moarvm
17:53 timotimo and now i've even done the groceries
17:57 dalek MoarVM/valgrind_support: e9b2cc9 | timotimo++ | src/ (8 files):
17:57 dalek MoarVM/valgrind_support: WIP on valgrind annotations
17:57 dalek MoarVM/valgrind_support:
17:57 dalek MoarVM/valgrind_support: gets the GC stage horribly wrong, at the moment
17:57 dalek MoarVM/valgrind_support: review: https://github.com/MoarVM/MoarVM/commit/e9b2cc9637
17:58 timotimo hm, the deopt annotations already print out what program counter inside the bytecode blob they deopt to, so i should be able to just throw resolve_annotation at that number and get the next available line number?
18:06 timotimo wow, that code was easy to write
18:06 timotimo let's see if it works
18:12 timotimo cool, seems to work
18:24 dalek MoarVM: 9bfcf87 | timotimo++ | src/spesh/dump.c:
18:24 dalek MoarVM: show line numbers for deopt annotations
18:24 dalek MoarVM:
18:24 dalek MoarVM: i would have prefered a line number for each beginning
18:24 dalek MoarVM: of a BB, but the deopt annotations directly come with a
18:24 dalek MoarVM: deopt index, so it's extremely convenient.
18:24 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/9bfcf87ae1
18:34 japhb joined #moarvm
19:15 jnthn I guess if we really want it it's cheap to annotate BBs with bytecode offset as we build the graph
19:15 jnthn Since we only need to actually resolve them (the more costly bit) as we dump
19:16 timotimo oh, so generating a deopt index for every beginning of a BB is very cheap?
19:17 jnthn I think it should be
19:18 jnthn In the second pass
19:18 jnthn for (i = 0; i < g->bytecode_size; i++) {
19:18 jnthn That i there is equivalent to a deopt index
19:19 jnthn (That's in build_cfg)
19:19 timotimo so i'd invent a new annotation type that's only for line numbers?
19:19 timotimo that gets ignored everywhere except in dumping
19:21 jnthn No
19:22 jnthn I'd add a field to MVMSpeshBb
19:22 jnthn *MVMSpeshBB
19:22 jnthn And just poke the index in there
19:24 timotimo ah, of course
19:25 timotimo should the deopt annotations keep the line number output, too?
19:26 timotimo maybe skip it if it's the same as the BB's line number
19:26 timotimo that'd mean we'd still have to resolve, though
19:27 timotimo do you have a good suggestion how to get at the cause of deopts?
19:30 jnthn deopts don't always go on BB boundaries
19:30 jnthn (so yeah, show both in the output)
19:30 timotimo yeah
19:31 timotimo but in this case i mean: how do we figure out which deopt exactly gets hit?
19:31 timotimo did you see? inside the match method, almost 100% of invocations end up locally deopting
19:31 timotimo for perl6 --profile -ne '.say if /^.x.*n.$/' /usr/share/dict/words
19:32 jnthn Check deopt.c for where we log them
19:32 jnthn You'll also have the index available
19:36 timotimo should that perhaps go into the profile as well?
19:36 timotimo a histogram of which deopt indices get hit how often?
19:37 jnthn Not sure how much they mean to the average profile reader...
19:37 timotimo fair 'nuff
19:37 jnthn But they can be useful to us :)
19:38 timotimo for this case, i'll just put a piece of code in that i'll kick out later
19:38 jnthn *nod*
19:38 jnthn Well, there already is some deopt logging printf's
19:38 timotimo yeah, i saw and was glad :)
19:39 timotimo i'll just have to put in the bytecodes along with the already existent filename and cuid
19:39 jnthn I'm never glad to see them 'cus it normally means I'm debugging a deopt bug :P
19:39 timotimo frame name*
19:39 timotimo ah, that's very true
19:44 timotimo this ... segfaults?!
19:44 timotimo i'll be distracted for ~30 minutes
19:48 jnthn Congrats :P
20:07 timotimo i don't understand the segfault, really
20:07 timotimo all the things i can inspect from inside gdb are not null-ish
20:09 timotimo oh, i was looking at the wrong line %)
20:09 timotimo MVMint32 deopt_target = find_deopt_target(tc, f, deopt_offset); - could this violently segfault if the deopt offset is wrong?
20:10 timotimo for example, much too big?
20:10 jnthn Probably
20:10 timotimo maybe i don't need deopt_all to report at all
20:18 timotimo the line it points at is             try $caller_dollar_slash = (@matches[0] // $cur.MATCH_SAVE);
20:19 timotimo 7868 on my m-CORE.setting
20:32 FROGGS uff, I added this line and I am not proud of it
20:32 FROGGS at least I think I did
20:33 timotimo now i have a second to actually look closely
20:33 timotimo sp_log r36(42), sslot(85)
20:33 timotimo getlex r42(25), lex(idx=7,outers=0,$!)
20:33 timotimo [Annotation: INS Deopt One (idx 118 -> pc 4416; line 7868)]
20:33 timotimo sp_log r42(25), sslot(86)
20:33 timotimo getlex r51(7), lex(idx=58,outers=2,Any)
20:33 timotimo that's the deopt right there; does that mean the $! lookup goes boom or that the Any lookup goes boom?
20:34 timotimo because i don't think the Any lookup ought to go boom. ever.
20:34 timotimo FROGGS: do you want more context to this so you can try to figure it out?
20:35 jnthn timotimo: Well, that's the after logging is insserted, but could do with looking at the after specialization too
20:35 FROGGS I don't even know what to figure out...
20:35 jnthn but yeah, it is something about the $!
20:35 FROGGS and I better prep my slides :S
20:35 jnthn If that really is "the one"
20:35 timotimo sure, i will
20:35 timotimo you go prep your slides :)
20:36 FROGGS thanks :o)
20:36 jnthn FROGGS: Know the feeling; I've a 3 hour-ish Perl 6 tutorial to do at the weekend...
20:36 timotimo getlex r42(25), lex(idx=7,outers=0,$!)
20:36 timotimo [Annotation: INS Deopt One (idx 118 -> pc 4416; line 7868)]
20:36 timotimo sp_guardconttype r42(25), sslot(54), sslot(55)
20:36 timotimo i wish i could tell you what's in these sslots exactly :S
20:37 jnthn Is there any kind of try earlier on in the method?
20:37 timotimo yes
20:37 timotimo in the "if $multi" branch
20:38 jnthn What if you set $! = Any after the try?
20:38 timotimo if $pat istype Regex, then it'll be executed
20:38 jnthn Or before the line that deopts?
20:38 timotimo well, both try's are mutually exclusive; does that matter?
20:38 jnthn Oh...
20:38 jnthn Hm
20:39 jnthn Then it can't be leftover stuff in the $!
20:41 timotimo i have a different deopt that shows up a whole lot now
20:41 timotimo i need to get a fresh speshlog
20:41 FROGGS jnthn: yes, but you are a good teacher and are used to it :o)
20:41 FROGGS but the good thing is, I can talk in Germish
20:42 jnthn FROGGS: Having to talk in Germish would make it harder for me :P
20:42 FROGGS though, I have to fill 40 minutes with my fast speaking 20 minutes talk I gave at the FOSDEM
20:42 FROGGS jnthn: true :P
20:42 jnthn FROGGS: I can say that experience doens't entirely eliminate the need to be prepared, sadly.
20:42 FROGGS aye
20:42 jnthn If this goes well and people like it, I may see if there's any interest to have it at YAPC::EU
20:43 jnthn I think there's some tutorial-y things there
20:43 FROGGS yeah
20:43 FROGGS at least at the YAPC::NA
20:48 timotimo wow, a gigantic amount of deopts inside ListIter.reify
20:49 timotimo but ... those don't show up in the profile at all!
20:49 timotimo anyway, adding $! = Any right before the "try" makes all the deopts turn to dust
20:49 timotimo well done, jnthn!
20:49 jnthn Innerestin'
20:50 jnthn Well, I'm not sure we should commit that
20:50 jnthn I'm curious for one why the try is there :)
20:50 jnthn But then also to look at if we can be smarter in Moar on this.
20:54 timotimo mhm
21:07 brrt joined #moarvm
21:07 brrt \o
21:08 timotimo yo brrt
21:08 brrt hi timotimo :-)
21:08 brrt did you rebase jit-devirt-reprops in its final form yet?
21:09 timotimo oh
21:09 timotimo i didn't
21:09 brrt i can if you wish
21:10 timotimo should be doable
21:10 timotimo i was doing stuff all over the place ;)
21:10 brrt oh, hey, by the way
21:10 timotimo well, the crazy amount of deopts in that "match" method wasn't too bad, as it was practically the last statement in there anyway
21:10 brrt my feed reader informed me jnthn++'s grant proposal has been accepted
21:10 timotimo and after that there was probably not terribly much that would have been better post-spesh
21:11 brrt deopting is still rather expensive if we've done inlining
21:12 timotimo does that mean deopting from inside an inlined piece?
21:12 brrt yes, or if we've inlined at all, although it's more expensive the deeper you go
21:13 brrt deopts are not a free lunch :-) much like invokish things
21:14 timotimo bindlex lex(idx=29,outers=0,<out of bounds>), r81(1) - this bodes well!
21:14 timotimo (just randomly looking at stuff)
21:19 timotimo hm, maybe that's because it's inlined and it's not looking at the lexpad of the result? or something?
21:21 brrt uh
21:21 brrt good question
21:21 timotimo there's inline annotations around that
21:22 timotimo well, it's followed by deopt inline markers
21:41 Peter_R joined #moarvm
21:48 timotimo 61.11user 0.15system 1:01.30elapsed 99%CPU (0avgtext+0avgdata 499076maxresident)k
21:49 timotimo 59.81user 0.16system 1:00.00elapsed 99%CPU (0avgtext+0avgdata 498956maxresident)k
21:49 timotimo that's without and with the $! = Any thing
21:51 timotimo so 479.529 times deopting takes 1.30 seconds longer than 479.833 times assigning Any to $!
22:28 jepeway_ joined #moarvm
22:36 vendethiel joined #moarvm
23:01 vendethiel joined #moarvm
23:31 vendethiel joined #moarvm

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