brrt . 07:54
good *
brrt1 clickbaits brrt-to-the-future.blogspot.nl/201...-want.html 16:54
lizmat whee! 17:05
timotimo hmpf. by merging "known value" annotations at phi nodes i get an nqp that doesn't compile, but also can't be bisected :( 20:10
so i'm randomly stumbling upon cursor_start 20:56
which is setting a few attributes with bindattr_i, but the facts i'm seeing tell me it should really be using a specialized, faster version 20:57
ooh, gdbgui looks shiny 21:16
timotimo it's because i broke it!! 22:02
jnthn brrt++ # nice post 22:08
.tell brrt "MoarVM in some places assumes that we have 'easy' access to the current instruction pointer, e.g. to lookup lexical variables" - did you mean s/lexical/dynamic/ ?
yoleaux jnthn: I'll pass your message to brrt.
timotimo the frame now has getspeshslot for the same slot and the same target local (though obviously multiple versions of it) in a row 22:14
huh, so ... 22:19
we can call '!cursor_start' on a NQPMatch type object and somehow accessing $!restart in that code can be just fine? 22:20
nope, i was wrong :) 22:22
so, the part of the code that could really use reaching the expr jit doesn't because it can't handle DEOPT_ONE on sp_guardtype; that's the guard that checks that $!restart is not set 22:23
i wonder what has to be done to make it capable of that? 22:24
we're apparently turning an isconcrete into a guardtype, though, that's a little overkill 22:25
or maybe we just don't have a "guardnonconcrete" 22:26
(we don't)
i see the comment in the source code says we don't do guards yet 22:27
maybe we actually want to prevent bb fusing after guard operations 22:28
oh yeah, this is rather a bit better 22:34
m: say 0x1b0 22:37
camelia 432
timotimo OK, the exprjit emits every getspeshslot as an identical tree of load and such 22:38
so maybe i should make this a spesh optimization 22:39
huh. the assembly that it spits out looks a whole lot longer, tbh 22:56
MasterDuke but is it faster? 22:59
Geth MoarVM: 9233d85e77 | (Timo Paulssen)++ | src/6model/reprs/P6opaque.c
fix copy-pasto and re-enable bindattr_* optimizations
 23:01
timotimo let me compare stage parse or something i guess 23:02
my system's currently under load 23:04
so hard to measure
Geth MoarVM/no_fuse_bb_after_guard: 146efce2c9 | (Timo Paulssen)++ | src/spesh/optimize.c
don't fuse BB right after a guard op

arguably the biggest beneficiary of fusing BBs is the exprjit. However, it currently bails out whenever it sees a sp_guard* op.		 23:05
timotimo MasterDuke: can you try it?
MasterDuke the commit on master or the branch?
timotimo both of them, and compare performance
MasterDuke seperately? 23:06
timotimo cursor_start is just a random frame i checked out; it'll change code all over the place
yeah, how fast is master, and is no_fuse_bb any faster
MasterDuke k 23:07
master seemed slightly faster, (parse or 79.3s, when it's usually 80 something) 23:09
hm, no_fuse_bb_after_guard took 87s 23:17
timotimo whaaaat 23:18
MasterDuke well, i ran it right after the master build, my laptop might have been throttling 23:19
doing another run
timotimo can you run both a few more times to see if the results are just noisy?
oh, laptop, yeah
MasterDuke it's plugged in, but...
timotimo you could try forcing the lowest frequency your laptop can handle
that way it won't do thermal throttling
not sure if you can easily disable all but one core, too ;)
MasterDuke i'll try on the desktop, that's a little less variable 23:22
timotimo thank you 23:27
MasterDuke timotimo: 3 runs right after each other on master = 78.something average 23:37
timotimo: 3 runs right after each other on no_fuse_bb_after_guard = 82.something average 23:38

Powered by Cro and the Raku® Programming Language.

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

Thank you!