|
00:53
lizmat joined
01:29
colomon joined
01:45
ilbot3 joined
01:52
avar joined,
colomon_ joined
02:48
ilbot3 joined
03:25
colomon joined
07:40
FROGGS[mobile] joined
08:19
lizmat joined
08:39
__rnddim__ joined,
xiaomiao joined
08:42
colomon_ joined
08:54
rurban joined
09:07
FROGGS joined,
FROGGS[mobile] joined
09:20
kjs_ joined
09:38
brrt joined
09:52
FROGGS joined
10:04
brrt left
10:18
rurban joined
10:24
synopsebot joined
11:18
vendethiel joined
11:41
ggoebel111111112 joined
12:08
brrt joined
12:31
sivoais joined
13:32
FROGGS joined
13:50
brrt joined
13:53
FROGGS[mobile] joined
15:05
FROGGS[mobile] joined
15:15
kjs_ joined
15:27
zakharyas joined
15:32
FROGGS[mobile] joined
16:32
LLamaRider joined
17:15
FROGGS[mobile] joined
17:19
FROGGS[mobile]2 joined
17:28
FROGGS[mobile] joined
17:42
FROGGS[mobile] joined
17:52
FROGGS[mobile] joined
17:55
rurban joined
18:10
FROGGS[mobile] joined
18:25
FROGGS[mobile] joined
19:13
colomon joined
19:32
kjs_ joined
19:33
colomon joined
19:44
colomon joined
19:59
colomon joined
20:10
kjs_ joined
20:52
zakharyas joined
21:37
kjs_ joined
22:10
kjs_ joined
22:23
brrt joined
22:32
chrisseaton joined
|
|||
| chrisseaton | hi - I was reading this presentation jnthn.net/papers/2014-yapceu-performance.pdf and it looks like MoarVM does AST specialisation before the JIT runs - is that the case? who's the expert on that because I'm interested in how you're doing it | 22:37 | |
| timotimo | it's not really AST specialization | 23:00 | |
| it's at the bytecode level | 23:01 | ||
| i'm not sure what exact part you're interested in, but i'd say it all begins at the callsite structure | 23:02 | ||
| where for every op in the bytecode we compile (into the .moarvm files) that has some kind of invocation semantic we reserve a callsite | |||
| chrisseaton | I work on the Truffle project - it's a language implementation framework that does AST specialisation via self-rewriting nodes based on profiling - so when I saw AST specialisation I was interested | ||
| timotimo | callsites store the number of required and optional positional arguments as well as the number (and names) of named arguments | ||
| equal callsites will be interned to become "the same callsite" | |||
| a callsite + a target code object gives us a "candidate", which can store how hot MoarVM considers it | 23:03 | ||
| and when it gets hot, we'll use the information from "what the callsite is" and a bit of extra information like "what types are common for these arguments" and create better bytecode for the target code object | 23:04 | ||
| do you have a moarvm installation on your machine already? | |||
| perhaps even a rakudo-moar compiler? | |||
| chrisseaton | no, never programmed Perl | ||
| timotimo | i never programmed perl 5 or earlier, either ;) | ||
| chrisseaton | I was reading the MoarVM source code though | ||
| timotimo | even when you just run "say('hello world')" in nqp-p, you'll get a sufficient amount of things that have been specialized | 23:05 | |
| let me just paste a log for you | |||
| sprunge.us/UMLe | 23:07 | ||
| specialization results in three pieces of dump being written: | |||
| first, when something is considered hot, we'll generate a version of the bytecode that logs types and values all over the place | |||
| that'll give you the blocks of "inserting logging information" with "before" and "after" | |||
| and when logging is finished (i think we run the same code about 10 times or so?) spesh will write out a new dump containing the bytecode after every optimization we've done | 23:08 | ||
| it's already bedtime for me over here | 23:09 | ||
| i hope my little overview was useful at all | |||
| i don't really see where you got the AST-based specialization thingie from, though | |||
| chrisseaton | yeah that's useful thanks - i'd call this bytecode 'quickening' | ||
| timotimo | this is all based on a SSA form of the bytecode | ||
| chrisseaton | jnthn.net/papers/2014-yapceu-performance.pdf | ||
| slide 15 definitely says the AST is specialised | |||
| timotimo | nope | 23:10 | |
| the optimizer is static | |||
| we only consider run-time optimizations that use run-time gathered data (like hotness and incoming types and used callsites) "specialization" | 23:11 | ||
| chrisseaton | does 'improved AST' refer to something else then? | ||
| timotimo | there's the NQP Optimizer and the Rakudo Optimizer (called "Perl 6 Optimizer" in the slides) that change AST | ||
| yes, the code-gen often spits out horribly bad ASTs | |||
| a very simple example is the AST for the regex / ^ "foo" / | 23:12 | ||
| chrisseaton | ah, I get it - the AST improvement is static before the byte code specialisation | ||
| ok thanks | |||
| timotimo | correct | ||
| the AST for that regex is "try to match the following at every point in the target text: is it the beginning of the string? if yes, does it say 'foo' here?" | |||
| that gets turned into "does it say 'foo' at the beginning of this string?" by the Regex Optimizer (that lives in nqp) | 23:13 | ||
| if you have more questions and have a bit of patience, you can just write them in here; i routinely backlog. other MVM developers do, too | 23:15 | ||
| chrisseaton | ok, thanks very much for that | 23:16 | |
| timotimo | you're welcome :) | ||
| i enjoy talking about stuff i'm enthusiastic about | |||
| (seems kind of tautologic) | |||
| japhb | timotimo: Some people like to *do* but not *talk*. Others like to do both. :-) | 23:39 | |
| timotimo | i've been a bit low on the "do" recently | 23:41 | |
| will pick up a bit more steam (no, not Steam) in a week at the very earliest | |||
| japhb | All my "do" is hidden in the shadows. Mildly frustrated that I have nothing visible at the moment. | 23:45 | |
| raydiak | can anyone check this out before I make a PR which includes it? I'm still new to moar and very fuzzy on c, but it looked quite wrong, to me: github.com/raydiak/MoarVM/commit/1...1845a85fe7 | 23:55 | |
| wanted to ask FROGGS++ himself, but lives'n'timezones'n'FOSDEMs'n'stuff have been frustrating that | 23:56 | ||