Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2014-07-12

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
03:05 cognominal joined #moarvm
03:46 FROGGS joined #moarvm
05:42 vendethiel joined #moarvm
07:41 timotimo maybe today i should look into how the "what op aborted jitting" log works and also have a look at what OSR thinks about the benchmarks
12:07 avar joined #moarvm
12:07 ChanServ joined #moarvm
12:07 TimToady joined #moarvm
12:07 japhb_ joined #moarvm
12:07 flussence joined #moarvm
12:07 japhb joined #moarvm
12:07 camelia joined #moarvm
12:07 cxreg joined #moarvm
12:07 harrow joined #moarvm
12:07 tokuhirom joined #moarvm
12:07 timotimo joined #moarvm
12:07 ashleydev joined #moarvm
12:07 BinGOs joined #moarvm
12:07 masak joined #moarvm
12:07 diakopter joined #moarvm
12:07 nwc10 joined #moarvm
12:07 krunen joined #moarvm
12:07 xiaomiao joined #moarvm
12:07 jnthn joined #moarvm
12:07 hoelzro joined #moarvm
13:01 carlin__ joined #moarvm
13:04 carlin joined #moarvm
13:14 timotimo i'm having difficulty figuring out which of the compilations in the jitlog corresponds to the benchmark's loop that got OSR'd
13:15 jnthn OSR and JIT don't interact yet...
13:16 jnthn Even if they did, it'd bail on something or other...
13:16 timotimo oh!
13:16 timotimo in that case, looking at the benchmarks we have already is probably nonsensical
13:17 timotimo what's the blocker on jit-osr-interaction?
13:19 jnthn No blocker really
13:20 jnthn Just one of those things still to do
13:24 timotimo all right
13:25 timotimo it seems like adding opcodes to the jit that can just be mapped to a c function call can be done without changing the dasm generated code
13:25 timotimo so maybe i'll add some of those. just don't know which ones are interesting at all
13:27 jnthn Well, if you want some real LHF there, you may find the trig functions are easy :)
13:32 timotimo there's only one type of container in MoarVM itself, the code container thingie; does that come up often in nqp code at all?
13:33 timotimo i saw quite a bunch of decont bails still
13:34 jnthn No, comes up rarely
13:34 jnthn Comes up rarely in Perl 6
13:34 jnthn Proxy uses it
13:35 timotimo so the decont bails inside nqp are all from "we don't know whether it's a container, but it most probably isn't"
13:36 jnthn Yeah
13:36 jnthn We don't know everything :)
13:36 timotimo hey, what about hllboxtype? i saw a few bails for that
13:37 timotimo hm, but that'd want to be done in dasm instead of a c function call
13:37 jnthn Yeah, but should be easy
13:37 timotimo well, there's the initial hump of setting up dynasm and the bit thingie module that it needs
13:37 jnthn Especially as the HLL config struct never moves
13:38 timotimo and the hll a frame belongs to also never changes, right?
13:39 jnthn Correct
13:39 timotimo but if we don't bail on hllboxtype, we'll probably have some boxing instruction next that'll be unimplemented for sure
13:39 timotimo so it's an LHF with very little gain, i expect
13:43 jnthn True, though those are function calls
13:43 timotimo oh!
13:43 timotimo as are bigint operations, for example, aren't they?
13:46 timotimo grep BAIL core_setting.jitlog | sort | uniq -c | sort -n ← simpler and probably also faster than the analysis script
13:46 timotimo the number one bailing operation is getattr_s, then checkarity and ifnonnull, then newlexotic and decont and then getdynlex
13:46 timotimo getattr_s causes 100 more bails than checkarity
13:47 timotimo getdynlex causes 45 more bails than getdynlex
13:47 timotimo the rest are spaced about 20 apart
13:48 timotimo not_i is the first one above 10
13:50 carlin joined #moarvm
13:51 timotimo getattr_s is at 295 bails, btw
13:51 jnthn hmm...that means there's a lot of attribute accesses that we currenlty don't spesh...
13:51 timotimo seems so
13:52 timotimo getattr_s is with a compile-time-constant string for the attribute name?
13:52 timotimo AFK for a bit
14:08 carlin joined #moarvm
14:44 timotimo is there something that keeps us from jitting checkarity to MVM_args_checkarity?
14:44 timotimo maybe the args structure isn't set up if we're in jitted code OSLT?
14:48 jnthn No, nothing stops us, afaik
14:49 timotimo cool, that seems like it'd get us further into many, many frames
15:07 timotimo but first: noms
16:18 vendethiel joined #moarvm
16:55 zakharyas joined #moarvm
18:22 carlin joined #moarvm
18:38 timotimo now i'm looking closer at how to implement checkarity; it seems like the "emit a c call for this op" approach codifies what to pass as the arguments with a bunch of constants, there's apparently not yet one for "the params structure"
18:39 timotimo so i would have to hack with dasc files if i wanted to implement that part
18:56 carlin joined #moarvm
19:03 jnthn ah...
19:03 jnthn Yeah...I guess better to check wiht brrt++ on that one then
19:04 timotimo i'm mildly confused, ack doesn't find the definitions of all those constants
19:05 timotimo but i'm also feeling a bit unmotivated to work on this now
19:05 timotimo did you make progress with the strings?
19:06 brrt joined #moarvm
19:06 brrt o/
19:06 jnthn Yes, some progress locally... Still at the everything broken stage.
19:06 timotimo speak of the devil!
19:06 jnthn Then I stopped to cook balti
19:06 jnthn Which was quite time-consuming :)
19:06 timotimo did you mean "baltimore"? :)
19:06 brrt the devil was reading the logs :-)
19:07 jnthn No, I meant the tasty Indian dish :P
19:07 jnthn o/ brrt
19:10 brrt ok, i've seen what MVM_args_checkarity does, and i have the following advice
19:11 brrt - a): either make a miniature wrapper that takes the tc and the two numbers in the op
19:11 brrt b): somehow implement the notion of 'the address of this or that struct value' - something i don't feel much for
19:12 brrt c): somehow implement that notion in the structure of a generic value type / expression tree, something i'm not very enthusiastic about, either
19:13 jnthn a) is probably better
19:14 jnthn checkarity will become rarer with time
19:14 brrt i think so too
19:16 brrt iirc, you can have access to the tc, the cu, and the frame as interp variables
19:16 brrt but, i'm off now
19:16 brrt o/
19:20 FROGGS joined #moarvm
19:28 carlin joined #moarvm
19:42 timotimo jnthn: how will the arguments to checkarity be represented in a spesh operand? it's supposed to be a uint16.
19:42 jnthn lit_i16 or so
19:42 jnthn We're...probably a bit fast and loose with signedness there.
19:42 timotimo hehehe.
19:43 timotimo well, we don't do calls with that many arguments yet
19:44 timotimo core setting compilation hasn't yet crashed, but i didn't look if any checkarity ops ended up in the jitted & executed portion yet
19:44 timotimo also, here's a thought
19:45 timotimo if the callsites have constant-sized argument count
19:45 timotimo er... i mean
19:45 timotimo the callsites we'll ever end up speshing
19:45 timotimo so checkarity would either immediately blow up in a spesh'd function, or never
19:45 timotimo so in theory, couldn't we just drop checkarity, since we never handle flattening callsites in spesh and thus the jit?
19:47 timotimo yeah, grepping for "emit opcode" results in zero times checkarity, so i can't determine if it would explode or work
19:48 dalek MoarVM/moar-jit: 2b66c53 | (Timo Paulssen)++ | src/ (3 files):
19:48 dalek MoarVM/moar-jit: teach the jit how to checkarity. might be wrong.
19:48 dalek MoarVM/moar-jit: review: https://github.com/MoarVM/MoarVM/commit/2b66c538d0
19:48 timotimo here's my attempt to call that function.
19:49 timotimo oh, i'd have access to the frame, eh? that'd probably be a bit better
19:50 timotimo with checkarity done, param_rp_o now has the 2nd place
19:52 timotimo since that op didn't  appear in the "bail" list before, i suppose all of these were preceded by checkarity so far, and apparently all except for 7 used-to-bail-with-checkarity frames now bail with that op
20:11 jnthn ah :)
20:11 jnthn Sounds quite feasible
20:11 jnthn spesh can't yet spesh callsites where the passed arg needs boxing or unboxing.
20:12 jnthn Was one of those "needs an extra reg" things
20:12 timotimo ah, okay
20:27 timotimo i suppose the 165 "ifnonnull" bails are going to be interesting
20:28 timotimo by far the most emitted opcodes in jitted code is 565x sp_getarg_o, followed by 467x set, 424x sp_getspeshslot
20:29 timotimo and then 161x sp_p6ogetvt_o, 116x sp_p6obind_o, 110x const_s, 53x getlex
20:31 timotimo there's about 10x as many "append_ins" lines compared to "emit op"
20:31 timotimo and those are only the ops that get thrown away *before* encountering a bail-causing op, not the ones that would come afterwards
20:33 timotimo oh, this count doesn't include c calls; unfortunately the c calls don't log what op they belonged to
21:15 vendethiel joined #moarvm
21:27 * jnthn did make progress on strings stuff today
21:27 FROGGS \o/
21:27 jnthn However, it's one of those refactors where you basically break everything and put it back together. I've got to the putting it back together phase by now. :)
21:28 FROGGS *g*
21:28 FROGGS yeah
21:28 FROGGS I am at the beginning of that phase in v5
21:29 vendethiel jnthn++ FROGGS++
21:29 FROGGS (still struggling with the NQPArray)
23:14 zakharyas joined #moarvm

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary