01:05 jnap1 left 01:58 FROGGS joined 02:59 btyler joined 06:09 bcode_ joined 06:10 flussence joined
sergot morning o/ 06:31
07:28 FROGGS joined 08:14 brrt joined
brrt \o moarning 08:15
FROGGS morning brrt 08:18
brrt: you are excited?
brrt morning froggs :-)
yes
about what, actually?
FROGGS looks like I'm becoming a soccer fan on my ol' days
brrt haha ok, i see 08:19
FROGGS :o)
brrt there's a difference between a soccer fan who watches world cups and a soccer fan
brrt can't find his glasses 08:20
found them
FROGGS hehe
I'm just the former for sure :o)
brrt yay, sigsegv 08:48
FROGGS \O/ 08:52
nwc10 .tell jnthn I made you a cut down test case: paste.scsys.co.uk/407344 09:01
botfail
FROGGS nwc10: do it in #perl6 09:03
brrt ok, trampolining now works 09:09
jnthn morning 09:10
brrt: bouncy bouncy 09:11
brrt morning jnthn :-)
you shot a nice hole in my 'lets return whether we the jit code is done' theory
because when optimizing jit-jit calls, that is not a good idea 09:12
FROGGS brrt: now you can put it on the wall and watch it :o9
:o)
brrt :-D
jnthn Well, yeah, you may need to fall back into the JIT again when returning... 09:13
If you're doing the "always returns" model
brrt the always returns model isn't viable 09:14
returns-is-coupled-to-return-instruction is probably better
jnthn bbi5 09:17
brrt hmm.. when are frames constructed? 09:23
oh, found it, fixed it 09:24
brrt has the feeling that x64 is much more sensitive to segv than x86 was 09:25
ok, now i'm at infinite looping 09:31
jnthn segv at least gives a point that's a problem :) 09:35
brrt that is quite rare, in my case, since most of the time the point doesn't represent any code 09:42
jnthn ah, true :)
brrt hmm.. i thought conditional jumps could take registers 09:43
but they can't 09:46
jnthn aww
brrt no matter, an unconditional can 09:48
whut, a set with equal source and destination operands 09:51
jnthn That can happen 09:52
spesh may do decont dest, src ==> set dest, src 09:53
If it doesn't need to decont
But it doesn't clear up the sets yet
Which sounds like an easy optimization except you can't quite just make it fall out of usage analysis because if you take away a set (or other instruction) that puts something that's used across a deopt boundary, and you deopt there, then the data could be missing post-deopt... 09:54
dalek arVM/moar-jit: 63e201a | (Bart Wiegmans)++ | src/ (9 files):
Add support for fastinvoke.

There are several weaknesses with the current approach, and I'll get to them in due course. Note that this is only visible if you disable inlining first.		 10:00
jnthn brrt: hehe, otherwise it will JIT-compile the inlined frame? 10:01
brrt yes, that's complex, and we'd have to find a way to have 'data restoration' aside from just frame restoration during deopt
jnthn Well, spesh knows where deopt boundaries are 10:02
So it can just factor that into it's analysis
I came up with a way to do that the other day
And now I seem to have forgotten it. tssk
brrt no, because the inliner wants too move the integer->object conversion to the frame instead of it being done by the return instruction
jnthn I'm sure it involved the dominator tree...
ah, yeah...
brrt can't really help there
jnthn np :) 10:03
brrt i've got to go run errands :-)
bbi3h
jnthn ok
o/
10:03 brrt left
jnthn nwc10: OK, sadly it doesn't blow up under anything here. 10:04
(anything I have)
10:04 cognominal joined
nwc10 jnthn: it's like this: paste.scsys.co.uk/407365 10:05
jnthn m: say 6400 / 8 10:08
camelia rakudo-moar 41574a: OUTPUTĀ«800ā¤Ā»
jnthn oh... 10:09
m: say 6400 / (8 * 4)
camelia rakudo-moar 41574a: OUTPUTĀ«200ā¤Ā»
nwc10 jnthn: try valgrind? paste.scsys.co.uk/407369 10:17
jnthn m: say 796 * 8 10:24
camelia rakudo-moar 41574a: OUTPUTĀ«6368ā¤Ā»
jnthn nwc10: Don't suppose you could try it with this patch: gist.github.com/jnthn/71d9084a495494f5bf2f 10:27
(and send me the output) 10:28
The data I get from it here doesn't add up to an overrun...
nwc10 from someone at work: pbs.twimg.com/media/BsEBVyPIYAEiFaQ.png - look, a scrollbar 10:45
jnthn lol 10:46
10:47 teodozjan joined
timotimo :D 10:48
jnthn The other clue I have on this is that there are some cases where we leave the routine before OSR logging is completed. 10:50
Then it's meant to degrade to normal logging. 10:51
nwc10 I'm redoing it with fprintf(stderr, ...) to get the output in the right order 10:52
OK, I thought that I was...
paste.scsys.co.uk/407382 10:55
logging at 796
logging at 800
==24858== Invalid write of size 8
jnthn huh, the 800 never happens here o.O
nwc10 that's probably the important poart
oh, curious
jnthn The highest I ever see is 796 10:56
nwc10 most strange
jnthn Things diverge after "logging at 796" 10:58
Seems your next entry is "OSR set up with 37 log slots" 10:59
Mine isn't that
I don't get the mass of 1s output either...what... 11:00
nwc10 yes, "what" ? 11:01
jnthn But...what in the script is meant to output those? 11:04
nwc10 say @b; 11:06
jnthn um...are we looking at the same script?
nwc10 that's in a block that was cut down from something longer in the original test
oh
I'm looking at the one in the URL on #perl6
jnthn There's no say @b in paste.scsys.co.uk/407344
nwc10 paste.scsys.co.uk/407345 11:07
that was the update
jnthn oh...
I'd assumed you'd linked me the same two...
nwc10 no, sorry
jnthn I get the 1s out now, but still it diverges a bit later 11:12
nwc10: I still struggle to replicate it, but I did find an off-by-one: gist.github.com/jnthn/f2538f88a794a1ca4516 11:21
nwc10 still have an invalid write :-( 11:33
jnthn :/ 11:34
nwc10: I'm betting gist.github.com/jnthn/90e65072fad8a978776f will fix it, but it's kinda a band-aid rather than hitting the root cause... 11:56
I think I mighta figured out the scenario where things go awry, though... 11:58
nwc10: gist.github.com/jnthn/206760395498553d4407 is latest 12:07
nwc10 OK, was going to finish the build & test of the previous
jnthn OK.
I need to eat :)
nwc10 this is a good plan.
jnthn So no hurry :)
nwc10 which reminds me to remind ilmari 12:08
jnthn Especially given the shop is an eating pre-req :)
12:11 cognominal joined 12:22 jnap joined
dalek arVM/moar-jit: 8d16619 | (Bart Wiegmans)++ | src/ (8 files):
Simplify JIT reentry (and renamed the label value)
 12:28
12:34 brrt joined
jnthn back 12:39
brrt too
i'm in need of sage advice again 12:40
the perennial question
'now what'
jnthn Invocation and returning now works? :)
Including the non-spesh invoke? 12:41
brrt no, non-spesh invoke doesn't work yet 12:42
jnthn OK, that's probably a good target while invocation is swapped in to your brain :)
12:45 cognominal joined 12:54 ggoebel111117 joined
jnthn nwc10: Any results, or tied up with other things? :) 13:00
nwc10 ASAN clean 13:01
building with ASAN to see what valgrind thinks
that is, ASAN is clean on the "bodge" version, and your believed-actual-fix 13:02
jnthn ok :)
nwc10 has not fixed the other ASAN error (the 3 threads in the lock test)
jnthn hunts the browser tab with that one 13:03
grr...can't find it :/ 13:06
nwc10 can regenerate, with current line numbers 13:07
==30944== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 9 from 9) 13:08
jnthn ok, thanks
nwc10 PASS. Or Score!
jnthn \o/
nwc10 or whatever it is
yes, \o/ I think is best 13:09
dalek arVM: 8b777f5 | jnthn++ | src/ (3 files):
Fix OSR issues when we didn't reach finalize.

Harden the logging increment check to make sure it never logs too much; this is more robust than the exit counter. If we are leaving an OSR'd frame without doing enough iterations, complete optimization anyway, since we know it's hot; this as a side-effect also avoids a number of potential races with bad behavior. nwc10++ for helping to track this one down.		 13:10
brrt brb :-) 13:11
14:12 ilbot3 joined
jnthn nwc10: I'm pretty sure that'll nail it. :) 14:12
nwc10 # FUDGED! 14:13
seems to. Will do full test
(takes a bit longer than a MoarVM rebuild)
14:15 synopsebot joined
lizmat so not time to bump MOAR_REVISION yet ? 14:18
14:26 brrt joined 14:27 carlin joined
nwc10 jnthn: yes. zero ASAN barf failures. 14:37
t/spec/S06-advanced/wrap.rakudo.moar fails actual tests
14:43 btyler joined
lizmat nwc10: that's a known one, and probably unrelated 14:51
jnthn Nice to be clean again. :) 14:58
lizmat I guess I'm gonna mark them as todo 14:59
[Coke] (please open a ticket for them, so I don't have to. :)
lizmat [Coke]: will do 15:01
nwc10 well, clean apart from that one 15:03
jnthn I meant ASAN-wise... 15:06
nwc10 yes, ASAN is barf-free
jnthn++ # taming ASAN
[Coke] lizmat++ 15:09
brrt much rejoice? 15:28
ok, i'm seeing a sp_getspeshslot between prepargs and invoke 15:39
jnthn ohhh 15:40
uh, yeah, those can sneak it.
By spesh
*in
brrt hmm
are they correct if they sneak in?
jnthn I *think* you can always pretend the thing happened before prepargs
Yes
It's done by the thingy that statically figures out what to call 15:41
Like, if it resolves a multi-dispatch
You'll typically find they come hand in hand with sp_fastinvoke
In theory we could try and make spesh shove them right before the prepargs...
brrt that would be ideal for my case 15:42
where would i find the source for this?
jnthn optimize.c
brrt i supposed so
jnthn Of note, optimize_call
line 529 is the money shot, I guess 15:43
arg_info will also let you locate the prep_args 15:44
*prepargs
brrt ok, very nice
jnthn So you'll want something like MVM_spesh_manipulate_insert_ins(tc, bb, the_preparg_ins->prev, ss_ins);
brrt uhuh 15:45
i'm checking it out :-) 15:46
thanks :-)
15:54 FROGGS[mobile] joined
dalek Heuristic branch merge: pushed 16 commits to MoarVM/moar-jit by bdw 16:00
brrt dalek++
ok, dinner& 16:05
jnthn nom well :)
16:13 FROGGS joined 16:22 cognominal joined
[Coke] bdw? 17:25
jnthn [Coke]: ? 17:32
17:34 brrt joined
brrt tnx 17:34
nwc10 jnthn: disable fixed size allocator and ASAN barfs on t/spec/integration/advent2010-day11.t 17:43
paste.scsys.co.uk/407476
[Coke] 12:00 < dalek> Heuristic branch merge: pushed 16 commits to MoarVM/moar-jit by bdw 17:44
FROGGS [Coke]: that's brrt 17:48
brrt bdw is the name of my github account, yes
17:57 woolfy1 joined
jnthn nwc10: If you set the env var MVM_SPESH_OSR_DISABLE, does it go away? 18:06
brrt moving sp_getspeshslot to before prepargs doesn't seem to cause any problems (as i expected it shouldn't :-)) 18:09
hmm 18:11
jnthn yeah, I'd have been very surprised if it did.
brrt i do get an error building rakudo, but that may be unconnected 18:12
FROGGS brrt: what error? 18:16
brrt let me see until it makes the error
Error while compiling op cleardispatcher: No registered operation handler for 'cleardispatcher' 18:17
FROGGS: is this a known error?
FROGGS brrt: this was added to nqp four days ago 18:18
brrt: looks like you just need to pull and build nqp and rakudo again
nwc10 jnthn: MVM_SPESH_OSR_DISABLE=1 and it still bargs 18:28
barfs
brrt seems so
(wrt to the nqp install)
(yay, JIT compiles no fewer than 326 fragments in the nqp compilation process) 18:29
timotimo hey, that's pretty good
do you have any data on how long these fragments end up being? 18:30
brrt not yet, should check the log
timotimo sounds very good, in any case :)
brrt yes, and apparantly, all fragments work, too 18:31
jnthn nwc10: Hm, OK. And, separately, MVM_SPESH_INLINE_DISABLE=1?
nwc10 pass
jnthn Aha. 18:32
brrt 249 bits in rakudo now
brrt expects that will be a greater number once invoke proper works
jnthn Still doesn't help me guess what's up, though...
OSR woulda narrowed it more.
timotimo d'aaw, the kitteh just let me pet 'is belly :3 18:33
dalek arVM/moar-jit: 66a7d29 | (Bart Wiegmans)++ | src/spesh/optimize.c:
Move sp_getspeshslot before prepargs in optimize_call

The optimizer sometimes inserts sp_getspeshslot node between the args instructions and the invoke instruction, which is annoying as it confuses the JIT, which likes to treat the sequence between prepargs and invoke as a single node.		 18:34
timotimo brrt: afair our regex parsing code would end up not getting jitted at all because it'd invoke so many times, right? 18:37
brrt ehm... i'm not sure i parse that correctly, but if it is called many times then i expect it to be jitted (eventually) 18:39
timotimo i meant the other way around :)
jnthn was confused too :)
timotimo regexes use invocations a bunch of times, in my recollection
jnthn I'm confused which bit was meant to be the other way around :P
timotimo but also there's a whole bunch of opcodes you probably didn't even look at yet, like "iscclass" and "findcclass" and the uniprop codes 18:40
though these could all be handled with C function calls i believe
brrt well, right
jnthn I think that regexes won't be getting JITted yet 'cus of...yes, all those.
brrt there is still plenty to do
timotimo if you give me a short template i could copypaste and tell me how to build and test my changes, maybe i can help with that at some point ... 18:41
brrt hmmm 18:42
that is a really good idea
timotimo if you write that as a guide rather than as a conversation with me, it'd benefit more people and my laziness wouldn't be so terrible :) 18:43
brrt that is an even better idea
timotimo going to commute around a bit now
brrt see you 18:44
dalek arVM/moar-jit: a36616c | (Bart Wiegmans)++ | / (6 files):
Add fast invoke flag to JIT invoke node
 18:51
19:00 btyler_ joined
brrt ok, invoke seems to work 19:14
jnthn \o/ 19:15
brrt++
FROGGS O.o
\o/
rurban brrt++
dalek arVM/moar-jit: b672fa1 | (Bart Wiegmans)++ | src/jit/emit_ (3 files):
Add support for 'proper' invoke calls
 19:16
brrt please try it out :-) (and let me know if i'm wrong)
anyway, i'm off for tonight :-) 19:17
19:17 brrt left
dalek arVM: bc4bb42 | jnthn++ | src/spesh/facts. (2 files):
Cope with cross-deopt-point usage analysis.

If a register gets used after a deopt point, give its usage an extra bump. This means we won't kill a write to it when doing dead code elimination. Even if we don't actually read it later in the optimized code, we still need things set up right for if we deopt. This extra care will allow us to be a little more aggresive in decrementing usage in various other situations.		 19:23
jnthn walk; bbiab 19:33
moritz jnthn: it seems like you're having great fun hacking on moarvm 19:36
FROGGS moritz: at least he can show his skills :o) 19:37
timotimo suh-weet! 19:48
hoelzro hup holland hup 20:20
jnthn Don't think this'll be another 7-1 :) 20:23
moritz: Yes, it's fun, though certain categories of bug are quite a pain to hunt.
hoelzro jnthn: I hope not 20:24
nwc10 All tests successful. 20:29
Files=903, Tests=31840, 566 wallclock secs (16.60 usr 4.54 sys + 10375.63 cusr 510.58 csys = 10907.35 CPU)
Result: PASS
jnthn: ^^^
(that's master/master/nom, back to the usual fixed sized allocator)
haven't had PASS in ages 20:30
jnthn++
jnthn nice :)
nwc10 "We have normality. I repeat, we have normality. Anything you still can't cope with is therefore your own problem."
jnthn Time to write more optimizations :P 20:31
nwc10 :-
)
20:35 teodozjan joined
FROGGS *g* 20:40
jnthn I'm not kidding, I'm working on two of them :P 20:44
FROGGS meh 20:45
:P
jnthn I think I mighta finally got lex2loc branch clean... 20:46
FROGGS ohh, I guess that feels good :o)
I am hacking on v5 to gain some motivation
20:51 itz__ joined
itz__ does bdw use irc? 20:54
jnthn Yes, he's brrt here
Though gone for the day, probably watching the foottie... :) 20:55
itz__ ah :)
20:55 brrt joined
brrt itz__: o/ 20:55
and yes, was watching, but its' commercial break 20:56
itz__ brrt: pull request to fix a simple typo .. two chars wrong way around
FROGGS here: github.com/MoarVM/MoarVM/pull/112
brrt oh, thanks for that 20:57
jnthn Nice to know folks are following the commits :)
brrt i'll pull it
dalek arVM/moar-jit: 22678c6 | (Steve Mynott)++ | src/jit/stub.c:
fix typo
arVM/moar-jit: ca998ba | (Bart Wiegmans)++ | src/jit/stub.c:
Merge pull request #112 from stmuk/moar-jit

fix typo
itz__ ty
brrt no, thank you :-)
also, if you want to try the actual jit compiler, you should configure with --enable-jit :-) 20:59
itz__ ah :) 21:01
21:02 teodozjan joined
brrt (soccer again :-)) 21:05
21:55 brrt left 22:32 jnap joined 22:53 dalek joined
dalek arVM/set-removal: 61ce13a | jnthn++ | src/spesh/optimize.c:
First pass at removing unrequried set ops.

This makes it all the way through the NQP build and test suite, all the way through the Rakudo build...then somehow manages to cause a bunch of Rakudo sanity tests to fail.		 23:13
japhb wonders how something can cleanly build the setting and fail large portions of sanity .... 23:15
jnthn I really have no idea! 23:18
And it's 1:20am so I'm not planning to find out right now :)
japhb Heh
Sleep well. :-) 23:19

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!