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
|
|||
brrt | . | 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,
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,
zakharyas joined
16:13
brrt1 joined
16:23
brrt joined
16:37
brrt1 joined
|
|||
brrt1 clickbaits brrt-to-the-future.blogspot.nl/201...-want.html | 16:54 | ||
lizmat | whee! | 17:05 | |
17:10
dogbert17 joined
17:38
zakharyas joined
17:40
AlexDaniel joined
17:50
AlexDaniel joined,
robertle joined
18:42
Kaiepi joined
19:08
Kaiepi joined
19:30
zakharyas joined
19:47
zakharyas joined
20:08
Kaiepi joined
|
|||
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 | ||
21:43
Kaiepi joined
|
|||
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 |