[00:14] *** committable6 joined [00:46] *** Kaiepi joined [00:50] *** Kaiepi joined [02:20] *** Kaiepi joined [02:58] *** ilbot3 joined [04:57] *** Geth joined [06:48] *** domidumont joined [07:04] *** brrt joined [07:14] *** domidumont joined [07:43] *** robertle joined [07:45] *** domidumont joined [07:54] . [07:54] good * [08:02] *** zakharyas joined [08:15] *** brrt joined [08:31] *** zakharyas joined [08:40] *** AlexDaniel joined [09:03] *** zakharyas joined [10:05] *** dogbert2 joined [10:29] *** zakharyas joined [10:57] *** brrt joined [11:39] *** brrt joined [12:20] *** brrt joined [12:42] *** dogbert2_ joined [12:42] *** committable6 joined [13:22] *** quotable6 joined [13:34] *** Geth joined [13:50] *** Kaiepi joined [13:52] *** Kaiepi joined [13:57] *** zakharyas joined [14:15] *** AlexDaniel joined [14:51] *** zakharyas joined [15:06] *** greppable6 joined [15:55] *** brrt joined [15:55] *** zakharyas joined [16:13] *** brrt1 joined [16:23] *** brrt joined [16:37] *** brrt1 joined [16:54] * brrt1 clickbaits https://brrt-to-the-future.blogspot.nl/2018/02/some-things-i-want.html [17:05] whee! [17:10] *** dogbert17 joined [17:38] *** zakharyas joined [17:40] *** AlexDaniel joined [17:50] *** AlexDaniel joined [17:50] *** robertle joined [18:42] *** Kaiepi joined [19:08] *** Kaiepi joined [19:30] *** zakharyas joined [19:47] *** zakharyas joined [20:08] *** Kaiepi joined [20:10] hmpf. by merging "known value" annotations at phi nodes i get an nqp that doesn't compile, but also can't be bisected :( [20:56] so i'm randomly stumbling upon cursor_start [20:57] 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 [21:16] ooh, gdbgui looks shiny [21:43] *** Kaiepi joined [22:02] it's because i broke it!! [22:08] 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/ ? [22:08] jnthn: I'll pass your message to brrt. [22:14] the frame now has getspeshslot for the same slot and the same target local (though obviously multiple versions of it) in a row [22:19] huh, so ... [22:20] we can call '!cursor_start' on a NQPMatch type object and somehow accessing $!restart in that code can be just fine? [22:22] nope, i was wrong :) [22:23] 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:24] i wonder what has to be done to make it capable of that? [22:25] we're apparently turning an isconcrete into a guardtype, though, that's a little overkill [22:26] or maybe we just don't have a "guardnonconcrete" [22:26] (we don't) [22:27] i see the comment in the source code says we don't do guards yet [22:28] maybe we actually want to prevent bb fusing after guard operations [22:34] oh yeah, this is rather a bit better [22:37] m: say 0x1b0 [22:37] rakudo-moar 52176c3c7: OUTPUT: «432␤» [22:38] OK, the exprjit emits every getspeshslot as an identical tree of load and such [22:39] so maybe i should make this a spesh optimization [22:56] huh. the assembly that it spits out looks a whole lot longer, tbh [22:59] but is it faster? [23:01] ¦ MoarVM: 9233d85e77 | (Timo Paulssen)++ | src/6model/reprs/P6opaque.c [23:01] ¦ MoarVM: fix copy-pasto and re-enable bindattr_* optimizations [23:01] ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/9233d85e77 [23:02] let me compare stage parse or something i guess [23:04] my system's currently under load [23:04] so hard to measure [23:05] ¦ MoarVM/no_fuse_bb_after_guard: 146efce2c9 | (Timo Paulssen)++ | src/spesh/optimize.c [23:05] ¦ MoarVM/no_fuse_bb_after_guard: don't fuse BB right after a guard op [23:05] ¦ MoarVM/no_fuse_bb_after_guard: [23:05] ¦ MoarVM/no_fuse_bb_after_guard: arguably the biggest beneficiary of fusing BBs [23:05] ¦ MoarVM/no_fuse_bb_after_guard: is the exprjit. However, it currently bails out [23:05] ¦ MoarVM/no_fuse_bb_after_guard: whenever it sees a sp_guard* op. [23:05] ¦ MoarVM/no_fuse_bb_after_guard: review: https://github.com/MoarVM/MoarVM/commit/146efce2c9 [23:05] MasterDuke: can you try it? [23:05] the commit on master or the branch? [23:05] both of them, and compare performance [23:06] seperately? [23:06] cursor_start is just a random frame i checked out; it'll change code all over the place [23:06] yeah, how fast is master, and is no_fuse_bb any faster [23:07] k [23:09] master seemed slightly faster, (parse or 79.3s, when it's usually 80 something) [23:17] hm, no_fuse_bb_after_guard took 87s [23:18] whaaaat [23:19] well, i ran it right after the master build, my laptop might have been throttling [23:19] doing another run [23:19] can you run both a few more times to see if the results are just noisy? [23:19] oh, laptop, yeah [23:19] it's plugged in, but... [23:19] you could try forcing the lowest frequency your laptop can handle [23:19] that way it won't do thermal throttling [23:19] not sure if you can easily disable all but one core, too ;) [23:22] i'll try on the desktop, that's a little less variable [23:27] thank you [23:37] timotimo: 3 runs right after each other on master = 78.something average [23:38] timotimo: 3 runs right after each other on no_fuse_bb_after_guard = 82.something average