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

Powered by Cro and the RakuĀ® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!