00:49 leego joined 05:53 domidumont joined 05:57 domidumont joined 07:20 zakharyas joined 07:22 brrt joined
brrt good * 07:50
nwc10 good brrt, *
brrt ohai nwc10 07:51
nwc10 even-moar-jit passes all spectests (apart from the newest one, until the merge made last night)
so now passes all spectests
brrt alright, cool :-), even with MVM_JIT_EXPR_ENABLE=1 ?
nwc10 ytes
brrt excellent
nwc10 but it's failing t/moar/50-jit-register-alloc.t
in NQP
brrt by design
:-)
nwc10 aha. you didnt' say that :-) 07:52
also, if I export MVM_JIT_EXPR_ENABLE=0
then that passes
brrt that test is explicitly there to test the failing register allocator
nwc10 which seems to prove something works :-)
brrt hehe
the bit i'm actually most proud of is the broken-expr-jit bisect tool
okay, then I'll move to a disable flag instead 07:53
timotimo brrt: did you see my little report last night? 08:30
brrt i did not 08:38
oh, nice work 08:39
the reason box_i, return_o are NYI is because I haven't done the CALL family of ops yes 08:40
and the reason they are NYI is because they require a good regional register allocator, which is currently not there yet
timotimo OK
how about return_o for example? is that also a CALL? 08:41
also, i was wondering: what if we generate (big parts of) interp.c out of the jit expr language? :)
brrt then you are at the point of the v8 interpreter project 08:42
timotimo is it a good place to be? :)
brrt 'ignition' i think it was called
yes, but
timotimo hehehe 08:43
it's a Single Source of Truth issue i expect
brrt that
and that we are currently still very much an object-oriented-C project, which is also a decently good place to be, just one that is slower than assembly ;-) 08:44
timotimo hm right
all the indirections, yes?
brrt yes 08:45
the same things that make the complexity manageable, i guess
have you ever heard of the parrot m0 project?
timotimo i'm not sure 08:46
brrt it was basically an idea to have a minimal-assembly like interpreter, (for which a JIT compiler could be developed), and port the 'upper crust' of parrot to that
timotimo oh
brrt that was a virtuous project, in the sense that it is complete hubris
timotimo so basically microcode?
brrt yeah. the thing is that then, you are going to have to implement a c-like language for your m0, and a debugger probably, too 08:47
none of that is especially hard, but nearly all of it is redundant compared to actually using the machine code 08:48
and the C compiler toolchain which already exists
and the fact that you are going to implement all the same object-cleverness, just on a different level
more to the point: the expr JIT is not now, nor will it be in the foreseeable future, as good as any of MSC++/Clang/GCC, in making fast bytecode 08:49
it is optimized for: small, extensible, hopefully reasonably fast 08:50
timotimo that'd be a tall ardor
order*
yeah, we don't necessarily want to ship a whole gcc everywhere we want moarvm to run
though maybe it isn't so bad?
brrt right. but the point is that the code in moar basically runs all the time, hence benefits much from the most-optimized-possible compilation 08:51
hence it makes sense to have GCC do that bit
timotimo ah. the interpreter, you mean by that
brrt yeah
timotimo and i suppose by extension most of the functions we've written so far
brrt well, there is an intermediate there 08:52
moving to an assembly-level interpreter is doable, but a huge project from where we are
… i say that and yet i'm not sure if it is true 08:53
it is large, at any rate
if we'd have templates for everything, then, yeah, maybe we could do it
more importantly., there is a bucketload of work to be done before we even get to that stage :-) 08:55
timotimo right 08:56
nine one step at a time 08:57
timotimo it was a far-future idea anyway
to replace interp.c (partially) by something generated from what we write in the expr jit templates
brrt it is a good idea, i think. LuaJIT also does something similar 08:58
somewhat similar, at least
in the category of cage cleaning: I want to have a more structured JIT log, more like the spesh log, than we currently have 08:59
timotimo thing is, if we generate c code from the exprjit, we'll still benefit from gcc's and clang's optimizations
yeah, it's a bit hard to read with the naked eye :)
what were you thinking of?
brrt not yet thinking… just complaining at an annoyance 09:00
timotimo what pieces of information do you usually look for when you open the log?
brrt - the structure of the bytecode that constructed the graph 09:01
- the resulting structure of the graph, including
- graph nodes
- tree structure
- labels
- the place, if any, where we stored the bytecode
- the register allocator output, preferably 09:03
timotimo btw, a neat trick i've learned for the graphviz thing: 09:07
if you want the root nodes to appear in a specific order, you can include a subgraph with "rankdir = LR" which contains edges (maybe in grey instead of black) between the roots in order of "execution" 09:08
konobi brrt: assuming you could create the dag plugin... apache's airflow might be a _really_ handy development and debugging tool for moarvm
brrt never heard of airflow 09:09
timotimo a toolkit for working with DAGs, apparently 09:11
intended for workflows
konobi a visual toolkit, specifically 09:12
brrt heh, that looks large-scale 09:37
jnthn
.oO( Web Scale! )
 09:39
timotimo DAG scale 09:41
jnthn Yo DAG, I heard you like graphs...
konobi the screenshots are a handy way to get an idea of the functionality 10:08
timotimo easier for something like airflow than for perl6 :S 10:09
brrt hehe
seems cool. no idea how hard it'd be to integrate that
or what we would do with it exactly 10:10
could possibly also work with spesh graphs i think
konobi brrt: it gives you the ability to look at the dag status over time 10:11
so you could find where an optimization wasn't possible and work back to why 10:12
brrt i see
that seems like it could work with spesh
just on first sight, i mean
konobi brrt: also see hot/cold paths, redundant paths, etc. 10:14
12:42 zakharyas joined 13:01 brrt left 13:21 avar joined 13:24 avar joined 13:57 FROGGS joined
timotimo so the ASSIGN-POS of NativeCall::Types (IntTypedCArray) has a param_rp_o for its self argument (it generates a getlexperinvtype for ::?CLASS, then a istype) is bailing from jitting because of the param_rp_o 14:36
do we have everything we need to know to turn that whole thing into something better? i.e. without a const_s, getlexperinvtype, and especially param_rp_o 14:37
jnthn getlexperinvtype getting so far as the JIT without being rewritten into something simpler (a spesh slot lookup, iirc) is a bit odd 14:40
So my first question would be "why ain't that happening"
timotimo this particular ASSIGN-POS only has one single log slot and it's filled from start to end with the same value: CArray[int32] 14:43
timotimo looks at what gets logged
ah, yes, that's the result of getlexperinvtype 14:44
15:18 zakharyas joined 15:54 domidumont joined 16:31 TimToady joined 16:48 domidumont joined 17:50 zakharyas joined 20:22 sivoais joined 21:27 Ven_ joined 21:32 sivoais joined 21:57 Ven_ joined 22:15 Ven_ joined 22:29 Ven_ joined 22:41 Ven_ joined 22:53 Ven_ joined 23:27 Ven_ 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!