github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
01:04 mgoebel left
ugexe is there something about _n ops that is/was more difficult to jit? specifically: eq_n, gt_n, lt_n, ge_n 03:26
asking because it would seem logical to implement the alongside their _i counterpart if it was that simple 03:28
MasterDuke ugexe: they're waiting on brrt's in-progress floating point support for the jit 03:31
ugexe ah. are there any other general things that cannot be jitted? attr related things like get/bindattr_* for instance? 03:34
MasterDuke i think a bunch of the param_* and *lex* ops are hard (maybe impossible, but i couldn't confirm that) 03:36
and *ctx* ops
looks like get/bindattr_* are jitted, but don't have templates, don't know why 03:38
ugexe what does it mean to be jitted but not have a template? my naive thinking would believe a template is a prereq to being jitted 03:39
MasterDuke other way around 03:40
there's still the legacy "lego" jit and the template/expression jit 03:41
and right now something has to be jitted in the lego jit before templates can be used 03:42
i *think* brrt has plans to eventually combine them (or maybe get rid of the lego jit), but i don't know any details 03:43
ugexe what file is the lego jit? / how do you know whats lego jitted already 03:45
MasterDuke src/jit/graph.c
if the spesh log mentions 'bailed completely' because of an op that usually means it's not jitted at all. when it sys 'expr bail: cannot get template' for an op that usually means it's lego jitted, but is missing the template 03:48
ugexe github.com/MoarVM/MoarVM/blob/5161...#L229-L230 04:04
i wonder if i dont need that for github.com/MoarVM/MoarVM/pull/1074/files 04:05
because return_i works if its not there, and that comment would make sense then 04:06
make sense to me rather
return_s worked with and without it 04:07
04:33 AlexDani` joined 04:37 AlexDaniel left
Geth MoarVM: ugexe++ created pull request #1075:
Add clone exprjit template		 05:53
MoarVM: 5a6b9ea30e | (Nick Logan)++ (committed using GitHub Web editor) | src/jit/core_templates.expr
Add clone exprjit template
 08:28
MoarVM: 138623b77e | niner++ (committed using GitHub Web editor) | src/jit/core_templates.expr
Merge pull request #1075 from ugexe/patch-10

Add clone exprjit template
09:04 patrickb joined 10:24 nine_ is now known as nine 11:29 AlexDani` is now known as AlexDaniel, AlexDaniel left, AlexDaniel joined 14:05 lucasb joined
dogbert17 m: say 'ping' 16:34
camelia ping
dogbert17 hmm, there seems to be a new bug lurking 16:40
it looks like this - gist.github.com/dogbert17/0aec4dfb...5bc7c1908b 16:42
could be a false positive ... 16:59
18:47 MasterDuke left 18:52 MasterDuke joined, MasterDuke left, MasterDuke joined
Geth MoarVM: ugexe++ created pull request #1076:
Add replace exprjit template		 19:29
MoarVM: ugexe++ created pull request #1077:
Add resume exprjit template		 19:39
MoarVM: ugexe++ created pull request #1078:
Add indexingoptimized exprjit template		 19:56
MoarVM: ugexe++ created pull request #1079:
Add typeparameterized exprjit template		 20:05
MoarVM: ugexe++ created pull request #1080:
Add typeparameterat exprjit template		 20:10
ugexe I think thats all the easy jit expr templates that were bailing for `zef search HTTP` 20:12
these are the remaining ones that look like they are not so easy: 20:13
assign, bindlex, captureexistsnamed, capturenamedshash, captureposarg, captureposarg_i, captureposelems, captureposprimspec, coerce_In, coerce_in, coerce_ni, coerce_ns, continuationinvoke, ctxcallerskipthunks, ctxlexpad, eq_n, expr, ge_n, getattrref_i, getcodename, getlexref_i, getlexref_n, getlexref_s, getlexreldyn, getwhere, gt_n, indexat, indexnat, invokewithcapture, jumplist, lexprimspec, lt_n,
p6capturelex, p6capturelexwhere, prepargs, queuepoll, rethrow, return, scwbdisable, sp_bind_n, sp_bind_s_nowb, sp_bool_I, sp_fastbox_bi_ic, sp_fastbox_i_ic, sp_get_s, sp_getlex_ins, sp_getlex_no, sp_getlex_o, sp_getlexvia_o, sp_guard, sp_guardconc, sp_guardjustconc, sp_guardjusttype, sp_guardobj, sp_guardsf, sp_guardtype, sp_p6oget_bi, sp_p6ogetvc_o, takehandlerresult, throwdyn, throwpayloadlex, unless_s,
wval_wide
how is "capturenamedshash" supposed to read? capture named shash? capture named s hash? 20:15
and by easy i mean the ones that can just be mapped to a function 20:19
could unless_s be implemented using MVM_string_compare($0, "") ? 20:34
or maybe checking the length 20:35
21:16 MasterDuke left
Geth MoarVM: ugexe++ created pull request #1081:
Add objectid exprjit template		 21:20
21:47 patrickb left 23:01 Kaiepi joined
ugexe decodeconf r57(2), r44(1), r57(1), r54(2) # JIT: bailed completely because of <decodeconf> <-- what does it mean that it bailed because of itself? 23:29
jnthn ugexe: capture nameds hash - a hash of all the named arguments in the capture
ugexe ah, the only one i didnt think it was
jnthn "bailed completely" means it's not even covered in the lego JIT 23:30
23:32 MasterDuke joined 23:33 MasterDuke left, MasterDuke joined
MasterDuke jnthn: all the profiles i've made in the past couple days have shown ~0% jit and everything is split between spesh and interpreted. i assume they are actually getting jitted, but i don't know where the problem is 23:34
or when exactly it started 23:36
jnthn MasterDuke: I saw something like that recently also, but had no time to figure out what was going on 23:40
If it was an actual JIT breakage I suspect we'd have seen a lot of benchmarks tank, though, and I didn't see any such reports, so I suspect it's a profiler issue somewhere 23:41
MasterDuke ok, glad (maybe?) it wasn't just me
btw, i think i've also seeing tons of identity() near the top of profiles recently, in gen/moar/BOOTSTRAP.nqp. is that because of some optimization of other stuff that it now bubbled up to the top? 23:44
jnthn It's a measure of profiler overhead as much as anything 23:46
MasterDuke is there a way to optionally exclude spesh itself from profiles? does that make sense?
jnthn No, I'm not sure what you mean. spesh runs on its own thread, so the meausre is how much of the program is was active for 23:47
*it was
identity is effectively `sub identity($a) { $a }` in NQP
A bunch of spesh plugins that determine no work is requied will resolve into it; it will then be inlined, and tend to optimzie into a single `set` instruction 23:48
MasterDuke i guess i'm sometimes unsure if something is from spesh (and there's probably nothing i can do about it), or from core and/or user code which i could possible do something about
jnthn Well, it's really just a normal sub 23:49
MasterDuke but i might not be very clear in my explanation (or correct in how i'm interpreting some of the stuff i see in profiles)
jnthn Just "called" very often
The reason it shows up heavily in profiles is, unfortunatley, measurement error 23:50
In the worst case I think it JITs into two machine code instructions
MasterDuke ah
jnthn So the enter and exit profiler instructions are what is actually getting measured 23:51
MasterDuke well, i gotta afk for a while, but thanks for the info
jnthn We might be able to somehow figure out that overhead and offset it somehow
MasterDuke hm, anyway to subtract those from costs? 23:52
jinx
jnthn In theory if we run (in C) a loop of profiler enter followed by profiler exit, and divide by the number of times we ran it, then we get a number that we could consider "the overhead"
We could perhaps do it at the start of profiling as a kind of "callibration" 23:53
And then provide that value with the data, so profiling frontends can subtract it
timotimo: You might find ^^ an interesting idea
timotimo interesting, yeah 23:55
jnthn I guess the answer to "has this bubbled up" is also yes: we used to do everything so slowly that the profiler noise didn't matter :P 23:59
.oO( Whenever we make something faster, all anybody notices is what's slow :P )

Powered by Cro and the Raku® Programming Language.

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

Thank you!