github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm Set by AlexDaniel on 12 June 2018. |
|||
00:00
reportable6 left
|
|||
Geth | MoarVM/master: 5 commits pushed by (Timo Paulssen)++ | 00:00 | |
00:02
reportable6 joined,
kiwi_65 joined
|
|||
timotimo | param_sn and param_sp are both :noinline, so now frames that use slurpy positionals can be inlined \o/ | 00:14 | |
and then of course there's the potential to scalar-replace small arrays and small hashes like the ones made by param_sp and param_sn respectively | 00:16 | ||
just scalar-replacing hashes that never get assigned to or read from would already be a little win, so that they only get materialized when deopt happens | 00:34 | ||
in many places, a slurpy hash parameter hash gets kept alive just by deopt points | |||
Kaiepi | what does spesh do? are there docs on it? | 00:37 | |
timotimo | it logs usage information about all code that's being executed | 00:39 | |
then it finds code that's "hot" enough to be considered for dynamic specialization (that's where "spesh" comes from) | 00:40 | ||
then it converts the bytecode of the "hot" frames into a form better suited for analysis (which is Static Single Assignment form, and splitting it into "basic blocks", linked together in a control-flow graph) | 00:41 | ||
after that, information about how the code gets invoked (how many parameters, what types) and what was logged during execution is used to make optimizations to the bytecode. some are "certain", but many are "speculative" and require guards to be inserted into the specialized code | 00:43 | ||
guards are cheap checks that allow the specialized code to jump back to unspecialized code to handle every general case | |||
one of the most important optimizations that spesh does is speculatively inline other code | |||
because it can figure out what happens to data that is passed from the caller to the callee and returned back out | 00:44 | ||
and more recently, partial escape analysis came to moarvm, which allows to speculatively not allocate objects until they really really have to be an actual object. until then, their attributes and such just get mapped to local variables (locals map to registers on moarvm) | 00:45 | ||
Kaiepi: does that help? | |||
Kaiepi | gimme a minute, i was afk | 00:46 | |
timotimo | haha | ||
jn's blog has loads of posts about spesh, and he's also given multiple talks that explain chunks of spesh | |||
Kaiepi | sounds like something i'd have to read to really understand | 00:48 | |
timotimo | setting MVM_SPESH_LOG=/tmp/blah.txt and running some random code can give you a bit of an idea what happens | ||
Kaiepi | there's still a lot of moarvm i have yet to read. i've dealt with i/o, nativecall, and reprs fairly closely but that's about it | 00:52 | |
and parts of the jit i guess | 00:53 | ||
the gc i'll need to pore through at some point before i finish my grant work so i don't screw up implementing async unix sockets | 00:54 | ||
01:06
MasterDuke left
01:19
lucasb left
03:07
squashable6 left,
squashable6 joined
03:10
kiwi_65 left
05:33
robertle left
05:55
brrt joined
|
|||
brrt | \o | 05:55 | |
nwc10 | o/ | 05:56 | |
brrt | timotimo: +1 on spesh-log-toolage | 05:59 | |
06:00
reportable6 left
06:01
reportable6 joined
06:19
fake_space_whale left
06:21
brrt left
06:41
rba left
06:42
rba joined
06:45
rba left,
rba joined
07:05
domidumont joined
07:27
sena_kun joined
07:28
sena_kun left
08:16
robertle joined
08:40
zakharyas joined
08:45
sena_kun joined
09:22
zakharyas left
09:40
camelia left
09:42
camelia joined,
zakharyas joined
09:55
brrt joined
10:01
zakharyas left
10:27
squashable6 left
10:32
brrt left,
squashable6 joined
11:18
brrt joined
12:00
reportable6 left
12:01
reportable6 joined
12:14
sena_kun left,
sena_kun joined
|
|||
Geth | MoarVM/master: 29 commits pushed by (Bart Wiegmans)++ review: github.com/MoarVM/MoarVM/compare/0...8283424598 |
12:33 | |
brrt | ^ that was 'jit-expr-float' | ||
timotimo | cool | 12:34 | |
brrt | bug reports at my address please... :-) | ||
on to the next! | 12:36 | ||
timotimo | linear nodes, right? | ||
12:51
domidumont left,
domidumont1 joined
|
|||
brrt | well, either that, or devirtualization | 12:54 | |
basically, I aim to leverage the expression template precompiler, to minimze the amount of rewriting I'll have to do for the linear IR | 12:55 | ||
jnthn | .oO( guards! ) |
13:01 | |
13:01
lucasb joined
|
|||
brrt | can't have them all at once | 13:03 | |
jnthn: ooc, do you mean, the deopt guards, or the spesh candidate guard tree? | 13:05 | ||
different problems | |||
jnthn | deopt guards | 13:07 | |
Many times, those are what seems to terminate the expr JIT's fun | |||
Though a few other things like sp_bind_o also seem to, which I guess is just missing templates | |||
brrt was looking at sp_bind_o recently, but forgot what happened there | 13:10 | ||
Ok.. I'll put it on my list... I actually don't think these should be hard? | |||
and they might benefit from named templates | 13:12 | ||
jnthn | Well, for guards, in terms of code size what'd be *really* nice is if we just set in some defined register the deopt point and then branched to a label with some code at the end, or some such | 13:18 | |
So that we don't bulk out the generated machine code with lots of calls to the deopt function | |||
And thus get better instruction cache usage | |||
We can maybe even do a conditional write of the deopt index (or just always write it to a register unconditionally, if that's cheaper) | 13:19 | ||
And then the code at an actual guard site becomes the guard + a (conditional) mov + a conditional branch, and if we don't deopt we don't take the branch. | |||
brrt | jnthn: 'call' sound suspiciously like the instruction you'd want :-D | 13:22 | |
for 'branch with a value in a predefined register' | |||
and... I agree... and this is totally possible. | |||
hmmmm. | 13:23 | ||
not sure, btw, if we can do conditional moves on literal values | 13:24 | ||
no, not with a literal | |||
... but we can always just use 'rax' for this.... | 13:33 | ||
since I have that as the spare register anyway | |||
AlexDaniel | timotimo: it did it again: colabti.org/irclogger/irclogger_lo...08-20#l136 | 14:13 | |
timotimo: although your idea of not sending the messages if the user replies kinda works! | |||
14:19
domidumont1 left
15:05
robertle left
15:21
brrt left
15:26
pamplemousse joined
|
|||
pamplemousse | o/ | 15:27 | |
15:40
sena_kun left
15:52
robertle joined
16:10
brrt joined
16:31
chloekek joined
16:39
brrt left
16:52
domidumont joined
17:15
brrt joined
17:39
brrt left
18:00
reportable6 left
18:04
reportable6 joined
18:39
MasterDuke joined
19:01
chloekek left
19:04
domidumont left
19:44
Ven`` joined
|
|||
MasterDuke | getcomp is tied for second place in causing number of `jit bailed completely` during a rakudo build. does it make any sense to try and jit it? or not, since it does the mutex locking? | 20:12 | |
20:13
pamplemousse left
|
|||
MasterDuke | it's tied with `param_on_o`. can the `param_on_*` ops be jitted? | 20:14 | |
20:14
Ven`` left
20:21
Ven`` joined
20:31
Ven`` left
20:39
chloekek joined
|
|||
MasterDuke | timotimo, et al.: any idea why valgrind complains that `Conditional jump or move depends on uninitialised value(s)` at github.com/MasterDuke17/libtommath...e067201R16 if you pass a malloced string instead of a calloced one? | 21:15 | |
21:59
robertle left
22:12
chloekek left
|
|||
jnthn | MasterDuke: I figur eyou know, but in case not: malloc doesn't zero memroy, calloc does | 22:54 | |
MasterDuke: Possible accident with failing to set the NULL terminator? | 22:55 | ||
MasterDuke: Also, probably wise to use snprintf | 22:58 |