01:34 FROGGS_ joined 01:37 zakharyas joined 01:47 ilbot3 joined 05:42 cognome joined
sergot o/ 06:39
nwc10 \o 07:20
07:24 lizmat joined
nwc10 jnthn: PASS apart from the sin 07:33
jnthn in what exactly? 07:38
nwc10 er, JIT
you merged your branch without deleting it 07:39
ie bccf73c36d9eb85ecc9e6aac13ed199848f23631
07:46 brrt joined
brrt \o 07:57
nwc10 o/ 07:58
jnthn nwc10: Yeah, I tend to do that asynchronously :P 08:18
nwc10 today you have a meeting? 08:20
jnthn had 08:21
'tis over by now :)
brrt all is well again
:-)
jnthn And a possible epic insanity has been avoided.
nwc10 excellent
the coffee was better today?
jnthn hah
Well, there was coffee sat in a pot 08:22
But I knew I was one of the first in today
nwc10 does masak drink coffee?
jnthn So knew better than to drink it
Not really
08:22 lizmat joined 08:27 woolfy joined
brrt i'm pondering splitting the graph.c hugefile ... probably best for cleanup week 08:27
jnthn aye 08:30
And only worth it if there's a natrual split
"number of lines in file" is a poor metric for nearly everything :) 08:31
brrt true 08:32
i think there are several natural splits: label management, c-call-node-building, the rest
nwc10 is the JIT branch mergable? 08:33
brrt but, each of these depends on JitGraphBuilder, which i kind of had hoped to be a one-off structure
nwc10: in terms of 'does it run', i should think that it is, at least what's on HEAD right now 08:34
in terms of 'is this clean enough to push to other people'... i don't know
we should probably want to erase the test nqp files in the directory
nwc10 isn't the current priority to get to "'is this clean enough to push to other people?' 'yes'" ? 08:35
brrt to be honest, my current current priority is 'handlers should work before i leave this over to other people' 08:36
i had planned to take next week for full cleanup 08:37
jnthn Yes, what's done now + handlers working = a very good state, imo 08:46
brrt (yay, moar with new label handling compiles \o/) 08:52
and segv!
jnthn Congrats! /o\ 08:53
brrt :-)
this one's easy
timotimo that sounds great!
FROGGS ha! but the bug behind that waiting to show up...
brrt and... no segv
FROGGS O.o 08:54
timotimo and jnthn will soon figure out in what exact way the inline_info calculation blows up and fix it :3
or maybe FROGGS will :)
i have a ENT appointment, as my ear infection seems to have recovered
FROGGS timotimo: I'd like to fix that NFA bug first
brrt i did break the deopt_all_idx thingy though 08:55
but, i'll get that working again
jnthn :) 08:56
jnthn has some work things to attend to today
masak .oO( timotimo's doctor is an ancient talking tree!? ) 08:58
brrt :-o code.google.com/p/unladen-swallow/...vantPapers 09:03
much wow
09:04 lizmat joined 09:05 woolfy joined, lizmat joined
masak wow indeed. 09:10
some weekend reading there :)
09:38 woolfy left 10:22 colomon_ joined 10:23 brrt joined
brrt wow, a jit code frame 11847 bytes large 10:23
jnthn so machine code 10:24
timotimo that just means we save so much more time because we don't have to interpret! :)
brrt would hope so 10:25
nwc10 but, as was said earlier, I-cache pressure 10:27
brrt might be having an off-by-one 10:28
jnthn I'm guessing a frame that large thats hot is a grammar rule somewhere 10:29
brrt yeah, i'm guessing so too 10:31
jnthn lunch & 10:33
brrt for when you come back; there should always be a deopt_all_idx if we're in deopt_all, or should it not? 10:39
apparantly, it's ok if there's not 10:40
dalek arVM/moar-jit: 0b3f99f | (Bart Wiegmans)++ | src/ (10 files):
Redo label handling for deopt and handler support

Instead of labels and offset, I now keep just indexes into the label array and indexes into the deopt array. Believe it or not, this makes quite a few things simpler, such as removing the necessity of a different OSR label array and a deopt_all label array. The goal is to make the construction of handler labels possible during graph construction, as well as inline labels.		 10:53
brrt huge commit coming up
tests passeth for me 11:01
tpfm :-)
bbi1h
nwc10 brrt: PASS (other than the usual sin) 11:19
jnthn wonders if that captures inline extents too :) 11:28
brrt: no, not every frame in the stack needs deopting
12:21 brrt joined
brrt jnthn: doesn't capture them yet, but is really simple to add 12:22
jnthn cool :) 12:23
12:28 cognome joined
brrt it seems codegen stores the frame handler offsets before writing the ops 12:32
jnthn It fills them in as it codegens, iirc 12:33
brrt yes, and the offsets are computed before, not after, so the labels will need to be before as well 12:37
12:53 jnap joined 12:58 itz_ joined 13:04 jnap joined 13:22 FROGGS[mobile] joined
brrt brb 13:23
14:08 brrt joined
jnthn will be away for some time 14:22
&
brrt why is hacking actually so much fun? 14:35
search_frame_handlers has only one caller it seems 14:41
14:41 ggoebel1111111 joined
brrt ugh, nearly there 15:05
search_frame_handler, y u so complex 15:11
talk about my ridiculous lines 15:12
15:17 zakharyas joined
brrt jnthn: if / when you're back, i'm in some need of more sage advice 16:20
it's really stupid, but still
hmm 16:32
know what
i'll just hack it in 16:33
timotimo gist.github.com/timo/ba36a47223115daeb6d0 - wow, that superb code-gen 17:58
18:04 japhb joined
japhb timotimo: Yeah, that's some wince-worthy code gen. But at least it's all the same type of problem, so can be fixed all at once. 18:07
Well, presumably.
timotimo not all of it is the very same problem 18:08
moarvm seems to exit without flushing stdout when dumping moar bytecode 18:10
otherwise i'd have a super juicy frame to show to you ... 18:11
japhb: refresh for a very juicy example of how we don't re-use registers %) 18:19
japhb wow 18:21
timotimo i don't know where that code gets generated :( 18:24
japhb Has anyone had a chance to look at the r-m benchmark regressions since 2014.07?
timotimo i think this code only runs once all in all
so it's not that terrible ... but it's something that'll contribute to start-up time ... maybe it'd just be a tiny fraction of a second faster if it would re-use the same local for all of these? 18:25
groceries &
japhb timotimo: It wouldn't surprise me if solving that problem (tight local lifetimes plus local reuse) would lead to performance improvements all over the place. 18:27
TimToady wonders if it's leftover parrot-think, where the vm was supposed to munch down the register count down 18:31
and the codegen only had to worry about uniqueness 18:32
japhb
.oO( Register allocators! Get your hot fresh register allocators here! )
 18:46
18:48 brrt joined
nwc10 it might be some other part of parrot-stuff 19:07
whereby every lexical needed to be refetched repeatedly
because in at least some cases it wasn't possible to assign to lexicals - the slot in the pad got rebound, rather than a new value copied to it 19:08
whatever, it looks like a fun targeted for someone to attack
"well volunteered"
timotimo o/ 19:40
what did i miss?
japhb timotimo: You volunteered to write a register allocator for our code gen. Don't you remember? 19:42
timotimo haha. 19:44
jnthn: i checked out latest moar-jit and --dump still complains: Unhandled exception: SC not yet resolved; lookup failed 19:49
now i can't test if my change improves the code-gen :\
20:29 jnap joined 21:19 brrt joined
brrt \o 21:19
timotimo: something special wrong with moar-jit? 21:21
argh even frame unwinding has to be altered 21:30
the long path to exceptions and frames JUST DOESN'T END 21:31
japhb brrt: We're just adding pluses to your grade at this point. The harder the journey ... 21:32
brrt i was told the grades didn't matter :-P
don't worry about me worrying about grades. i'll do that when this is long over 21:33
japhb I was speaking metaphorically. :-) 21:34
timotimo brrt: nah, it's just jnthn says he'd fixed moarvm code dumping with a patch that's only on moar-jit
brrt ah ok
good :-)
brrt should commit 21:36
timotimo i'd appreciate that :) 21:37
not that i could help or something :S
brrt well, it's broken too 21:40
and it should be broken, too :-)
i can push it to a 'its broken' branch
timotimo OK
dalek arVM/jit-handlers: 2641788 | (Bart Wiegmans)++ | src/core/ (3 files):
Simplify die so it's more JIT-able
 21:43
arVM/jit-handlers: 1159e41 | (Bart Wiegmans)++ | / (12 files):
WIP on Handler support.

This crashes after returning from the handler, as I suppose it should, because I haven't fixed hanlder invocation yet.
brrt is off drinking beer 21:44
i should be able to fix this tomorrow morning :-)
'night #moarvm 21:45
21:45 brrt left
japhb 'night, brrt 21:47
23:08 woolfy joined 23:33 lizmat joined 23:38 woolfy left
jnthn So beer. :) 23:59
japhb \o/ # jnthn + beer

Powered by Cro and the Raku® Programming Language.

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

Thank you!