timotimo if i merge jit_devirtualize_reprops, we'll be able to throw out a roadmap entry that's targeted at 2015.06 00:31
and if i do it now-ish, we'll have plenty of testing until the release 00:32
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 00:33
01:55 synbot6 joined 01:58 synbot6 joined 02:47 synbot6 joined 03:03 harrow joined 06:54 jepeway joined 06:57 zakharyas joined 07:26 Ven_ joined 07:29 brrt joined
brrt timotimo: i'm for it 07:34
timotimo oh hey brrt
brrt i'll run a spectest asap
oh hi :-)
just for my clarity
which branch is it you want to merge
timotimo jit_devirtualize_reprops_3 07:37
i might rebase it before i attempt a merge
brrt try one without a number 07:50
:-P
timotimo ? 07:53
brrt well, imho there's no reason to tag numbers to branches 08:07
especially if you progress linearly on them
timotimo i rebased 3 times 08:15
er
2 times
brrt ah well 08:16
i see
08:27 Ven_ joined
timotimo implicit declaration of function ā€˜pthread_yieldā€™ - has this always been there? 08:41
jnthn kinda
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
i don't remember having seen that. but okay
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. 08:43
09:19 dalek joined 09:53 harrow joined 10:13 harrow joined 10:14 Ven_ joined 10:54 Ven_ joined 11:21 harrow joined 11:29 brrt joined 11:40 harrow joined 11:44 rurban joined 12:14 ggoebel joined 12:26 harrow joined 12:45 harrow joined
dalek arVM/jsoff: 002bd16 | FROGGS++ | / (10 files):
foo
 13:09
arVM/jsoff: be79531 | FROGGS++ | src/ (3 files):
sandbox: attempt to implement scdisclaim op
brrt what, why 13:19
lizmat to be able to precomp an arbitraty data structure 13:21
perhaps ?
brrt hmm ok 13:22
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
jnthn *nod* 14:05
FROGGS jnthn: funny is, $a = deserialize(); $a.push(1); serialize($a) breaks while .unshift there works
jnthn Did you have to disable lazy des, 'cus the code you wrote looks like it should work out...
o.O 14:06
I wonder if you're not clearing the SC entirely?
FROGGS I disabled it
I think I do, from looking at the debug output
jnthn See if an SC WB is hit on push?
FROGGS how do I do that? 14:07
timotimo++ suggested that too
14:08 harrow joined
jnthn I'd just put a breakpoint (or debug code) in the sc.c function that is called if it is. 14:09
FROGGS MVM_sc_wb_hit_obj? 14:10
jnthn Yes 14:12
FROGGS well, I hit the same amount of WBs for push and unshift it seems
jnthn hm 14:16
FROGGS jnthn: I also added test files to rakudo/jsoff 14:22
ser.pl and Ser.pm
I test it as: unlink TEST_FILE; perl6 ser.pl; perl6 ser.pl; perl6 ser.pl 14:23
tadzik :D
ser is still there 14:24
FROGGS it explodes by that time when using push in ser.pl
still?
timotimo .o( i haven't seen sergot in a while, have i? )
tadzik I think it started as emmentallers 'sergenerator.pl' or somtehing
ser being polish for cheese
FROGGS haha
tadzik we can now invent some fancy acronym for ser and pretend it was about testing all along 14:25
14:26 Ven_ joined
FROGGS walk & 14:28
[Coke] "eating your own cheese" 14:59
tadzik yum 15:23
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:13
hm, i'll probably have to go through the deopt table 16:17
16:19 JimmyZ_ joined
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:21
16:22 resr_ joined
timotimo hurm. in reify, "while $!rest && (nqp::elems($rpa) < $count)' gets a full call into &infix:Ā«<Ā» generated >_< 16:31
even though $count is an int declared variable
and that is where the 5.759.092 IntLexRef objects get created in my benchmark
lizmat perhaps a nqp::islt_i is in order ?
timotimo nqp: say(nqp::islt_i(5, 10)); 16:32
:o
did i just kill camelia?
lizmat m: use nqp; say(nqp::islt_i(5, 10));
timotimo wait for 'er to come back first, will ya? :S
lizmat hehe
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
16:33 camelia joined
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"
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ā¤Ā»
timotimo i'm not really +1 to changing the < to the islt_i 16:37
i'd rather our code gen does it automatically (again)
lizmat fine by me... :-) 16:38
when that happens, we can get rid of a lot of nqp:: code in various places :-)
timotimo mhm
i'm not saying the core setting has to be pretty, but it doesn't have to be more obfuscated than necessary 16:39
16:41 vendethiel joined
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?
jnthn In NQP maybe :) 16:46
jnthn doesn't remember especially working on that in Rakudo 16:47
16:59 FROGGS[mobile] joined
timotimo i'm now in front of a computer again and can look into the nqp::elems thing 17:09
17:14 vendethiel joined 17:33 camelia joined 17:36 camelia joined
timotimo and now i've even done the groceries 17:53
dalek arVM/valgrind_support: e9b2cc9 | timotimo++ | src/ (8 files):
WIP on valgrind annotations

gets the GC stage horribly wrong, at the moment		 17:57
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? 17:58
wow, that code was easy to write 18:06
let's see if it works
cool, seems to work 18:12
dalek arVM: 9bfcf87 | timotimo++ | src/spesh/dump.c:
show line numbers for deopt annotations

i would have prefered a line number for each beginning of a BB, but the deopt annotations directly come with a deopt index, so it's extremely convenient.		 18:24
18:34 japhb joined
jnthn I guess if we really want it it's cheap to annotate BBs with bytecode offset as we build the graph 19:15
Since we only need to actually resolve them (the more costly bit) as we dump
timotimo oh, so generating a deopt index for every beginning of a BB is very cheap? 19:16
jnthn I think it should be 19:17
In the second pass 19:18
for (i = 0; i < g->bytecode_size; i++) {
That i there is equivalent to a deopt index
(That's in build_cfg) 19:19
timotimo so i'd invent a new annotation type that's only for line numbers?
that gets ignored everywhere except in dumping
jnthn No 19:21
I'd add a field to MVMSpeshBb 19:22
*MVMSpeshBB
And just poke the index in there
timotimo ah, of course 19:24
should the deopt annotations keep the line number output, too? 19:25
maybe skip it if it's the same as the BB's line number 19:26
that'd mean we'd still have to resolve, though
do you have a good suggestion how to get at the cause of deopts? 19:27
jnthn deopts don't always go on BB boundaries 19:30
(so yeah, show both in the output)
timotimo yeah
but in this case i mean: how do we figure out which deopt exactly gets hit? 19:31
did you see? inside the match method, almost 100% of invocations end up locally deopting
for perl6 --profile -ne '.say if /^.x.*n.$/' /usr/share/dict/words
jnthn Check deopt.c for where we log them 19:32
You'll also have the index available
timotimo should that perhaps go into the profile as well? 19:36
a histogram of which deopt indices get hit how often?
jnthn Not sure how much they mean to the average profile reader... 19:37
timotimo fair 'nuff
jnthn But they can be useful to us :)
timotimo for this case, i'll just put a piece of code in that i'll kick out later 19:38
jnthn *nod*
Well, there already is some deopt logging printf's
timotimo yeah, i saw and was glad :)
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
timotimo frame name*
ah, that's very true
this ... segfaults?! 19:44
i'll be distracted for ~30 minutes
jnthn Congrats :P 19:48
timotimo i don't understand the segfault, really 20:07
all the things i can inspect from inside gdb are not null-ish
oh, i was looking at the wrong line %) 20:09
MVMint32 deopt_target = find_deopt_target(tc, f, deopt_offset); - could this violently segfault if the deopt offset is wrong?
for example, much too big? 20:10
jnthn Probably
timotimo maybe i don't need deopt_all to report at all
the line it points at is try $caller_dollar_slash = (@matches[0] // $cur.MATCH_SAVE); 20:18
7868 on my m-CORE.setting 20:19
FROGGS uff, I added this line and I am not proud of it 20:32
at least I think I did
timotimo now i have a second to actually look closely 20:33
sp_log r36(42), sslot(85)
getlex r42(25), lex(idx=7,outers=0,$!)
[Annotation: INS Deopt One (idx 118 -> pc 4416; line 7868)]
sp_log r42(25), sslot(86)
getlex r51(7), lex(idx=58,outers=2,Any)
that's the deopt right there; does that mean the $! lookup goes boom or that the Any lookup goes boom?
because i don't think the Any lookup ought to go boom. ever. 20:34
FROGGS: do you want more context to this so you can try to figure it out?
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...
jnthn but yeah, it is something about the $!
FROGGS and I better prep my slides :S
jnthn If that really is "the one"
timotimo sure, i will
you go prep your slides :)
FROGGS thanks :o) 20:36
jnthn FROGGS: Know the feeling; I've a 3 hour-ish Perl 6 tutorial to do at the weekend...
timotimo getlex r42(25), lex(idx=7,outers=0,$!)
[Annotation: INS Deopt One (idx 118 -> pc 4416; line 7868)]
sp_guardconttype r42(25), sslot(54), sslot(55)
i wish i could tell you what's in these sslots exactly :S
jnthn Is there any kind of try earlier on in the method? 20:37
timotimo yes
in the "if $multi" branch
jnthn What if you set $! = Any after the try? 20:38
timotimo if $pat istype Regex, then it'll be executed
jnthn Or before the line that deopts?
timotimo well, both try's are mutually exclusive; does that matter?
jnthn Oh...
Hm
Then it can't be leftover stuff in the $! 20:39
timotimo i have a different deopt that shows up a whole lot now 20:41
i need to get a fresh speshlog
FROGGS jnthn: yes, but you are a good teacher and are used to it :o)
but the good thing is, I can talk in Germish
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
jnthn: true :P
jnthn FROGGS: I can say that experience doens't entirely eliminate the need to be prepared, sadly.
FROGGS aye
jnthn If this goes well and people like it, I may see if there's any interest to have it at YAPC::EU
I think there's some tutorial-y things there 20:43
FROGGS yeah
at least at the YAPC::NA
timotimo wow, a gigantic amount of deopts inside ListIter.reify 20:48
but ... those don't show up in the profile at all! 20:49
anyway, adding $! = Any right before the "try" makes all the deopts turn to dust
well done, jnthn!
jnthn Innerestin'
Well, I'm not sure we should commit that 20:50
I'm curious for one why the try is there :)
But then also to look at if we can be smarter in Moar on this.
timotimo mhm 20:54
21:07 brrt joined
brrt \o 21:07
timotimo yo brrt 21:08
brrt hi timotimo :-)
did you rebase jit-devirt-reprops in its final form yet?
timotimo oh 21:09
i didn't
brrt i can if you wish
timotimo should be doable 21:10
i was doing stuff all over the place ;)
brrt oh, hey, by the way
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
brrt my feed reader informed me jnthn++'s grant proposal has been accepted
timotimo and after that there was probably not terribly much that would have been better post-spesh
brrt deopting is still rather expensive if we've done inlining 21:11
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
deopts are not a free lunch :-) much like invokish things 21:13
timotimo bindlex lex(idx=29,outers=0,<out of bounds>), r81(1) - this bodes well! 21:14
(just randomly looking at stuff)
hm, maybe that's because it's inlined and it's not looking at the lexpad of the result? or something? 21:19
brrt uh 21:21
good question
timotimo there's inline annotations around that
well, it's followed by deopt inline markers 21:22
21:41 Peter_R joined
timotimo 61.11user 0.15system 1:01.30elapsed 99%CPU (0avgtext+0avgdata 499076maxresident)k 21:48
59.81user 0.16system 1:00.00elapsed 99%CPU (0avgtext+0avgdata 498956maxresident)k 21:49
that's without and with the $! = Any thing
so 479.529 times deopting takes 1.30 seconds longer than 479.833 times assigning Any to $! 21:51
22:28 jepeway_ joined 22:36 vendethiel joined 23:01 vendethiel joined 23:31 vendethiel joined

Powered by Cro and the RakuĀ® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!