Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2016-09-16

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

All times shown according to UTC.

Time Nick Message
00:49 leego joined #moarvm
05:53 domidumont joined #moarvm
05:57 domidumont joined #moarvm
07:20 zakharyas joined #moarvm
07:22 brrt joined #moarvm
07:50 brrt good *
07:50 nwc10 good brrt, *
07:51 brrt ohai nwc10
07:51 nwc10 even-moar-jit passes all spectests (apart from the newest one, until the merge made last night)
07:51 nwc10 so now passes all spectests
07:51 brrt alright, cool :-), even with MVM_JIT_EXPR_ENABLE=1 ?
07:51 nwc10 ytes
07:51 brrt excellent
07:51 nwc10 but it's failing t/moar/50-jit-register-alloc.t
07:51 nwc10 in NQP
07:51 brrt by design
07:51 brrt :-)
07:52 nwc10 aha. you didnt' say that :-)
07:52 nwc10 also, if I export MVM_JIT_EXPR_ENABLE=0
07:52 nwc10 then that passes
07:52 brrt that test is explicitly there to test the failing register allocator
07:52 nwc10 which seems to prove something works :-)
07:52 brrt hehe
07:52 brrt the bit i'm actually most proud of is the broken-expr-jit bisect tool
07:53 brrt okay, then I'll move to a disable flag instead
08:30 timotimo brrt: did you see my little report last night?
08:38 brrt i did not
08:39 brrt oh, nice work
08:40 brrt the reason box_i, return_o are NYI is because I haven't done the CALL family of ops yes
08:40 brrt and the reason they are NYI is because they require a good regional register allocator, which is currently not there yet
08:40 timotimo OK
08:41 timotimo how about return_o for example? is that also a CALL?
08:41 timotimo also, i was wondering: what if we generate (big parts of) interp.c out of the jit expr language? :)
08:42 brrt then you are at the point of the v8 interpreter project
08:42 timotimo is it a good place to be? :)
08:42 brrt 'ignition' i think it was called
08:42 brrt yes, but
08:43 timotimo hehehe
08:43 timotimo it's a Single Source of Truth issue i expect
08:43 brrt that
08:44 brrt 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
08:44 timotimo all the indirections, yes?
08:45 brrt yes
08:45 brrt the same things that make the complexity manageable, i guess
08:45 brrt have you ever heard of the parrot m0 project?
08:46 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
08:46 timotimo oh
08:46 brrt that was a virtuous project, in the sense that it is complete hubris
08:46 timotimo so basically microcode?
08:47 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:48 brrt none of that is especially hard, but nearly all of it is redundant compared to actually using the machine code
08:48 brrt and the C compiler toolchain which already exists
08:48 brrt and the fact that you are going to implement all the same object-cleverness, just on a different level
08:49 brrt 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:50 brrt it is optimized for: small, extensible, hopefully reasonably fast
08:50 timotimo that'd be a tall ardor
08:50 timotimo order*
08:50 timotimo yeah, we don't necessarily want to ship a whole gcc everywhere we want moarvm to run
08:50 timotimo though maybe it isn't so bad?
08:51 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 brrt hence it makes sense to have GCC do that bit
08:51 timotimo ah. the interpreter, you mean by that
08:51 brrt yeah
08:51 timotimo and i suppose by extension most of the functions we've written so far
08:52 brrt well, there is an intermediate there
08:52 brrt moving to an assembly-level interpreter is doable, but a huge project from where we are
08:53 brrt … i say that and yet i'm not sure if it is true
08:53 brrt it is large, at any rate
08:53 brrt if we'd have templates for everything, then, yeah, maybe we could do it
08:55 brrt more importantly., there is a bucketload of work to be done before we even get to that stage :-)
08:56 timotimo right
08:57 nine one step at a time
08:57 timotimo it was a far-future idea anyway
08:57 timotimo to replace interp.c (partially) by something generated from what we write in the expr jit templates
08:58 brrt it is a good idea, i think. LuaJIT also does something similar
08:58 brrt somewhat similar, at least
08:59 brrt 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
08:59 timotimo yeah, it's a bit hard to read with the naked eye :)
08:59 timotimo what were you thinking of?
09:00 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?
09:01 brrt - the structure of the bytecode that constructed the graph
09:01 brrt - the resulting structure of the graph, including
09:01 brrt - graph nodes
09:01 brrt - tree structure
09:01 brrt - labels
09:01 brrt - the place, if any, where we stored the bytecode
09:03 brrt - the register allocator output, preferably
09:07 timotimo btw, a neat trick i've learned for the graphviz thing:
09:08 timotimo 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
09:09 brrt never heard of airflow
09:11 timotimo a toolkit for working with DAGs, apparently
09:11 timotimo intended for workflows
09:12 konobi a visual toolkit, specifically
09:37 brrt heh, that looks large-scale
09:39 jnthn .oO( Web Scale! )
09:41 timotimo DAG scale
09:41 jnthn Yo DAG, I heard you like graphs...
10:08 konobi the screenshots are a handy way to get an idea of the functionality
10:09 timotimo easier for something like airflow than for perl6 :S
10:09 brrt hehe
10:09 brrt seems cool. no idea how hard it'd be to integrate that
10:10 brrt or what we would do with it exactly
10:10 brrt could possibly also work with spesh graphs i think
10:11 konobi brrt: it gives you the ability to look at the dag status over time
10:12 konobi so you could find where an optimization wasn't possible and work back to why
10:12 brrt i see
10:12 brrt that seems like it could work with spesh
10:12 brrt just on first sight, i mean
10:14 konobi brrt: also see hot/cold paths, redundant paths, etc.
12:42 zakharyas joined #moarvm
13:01 brrt left #moarvm
13:21 avar joined #moarvm
13:24 avar joined #moarvm
13:57 FROGGS joined #moarvm
14:36 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:37 timotimo 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:40 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 jnthn So my first question would be "why ain't that happening"
14:43 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
14:44 timotimo ah, yes, that's the result of getlexperinvtype
15:18 zakharyas joined #moarvm
15:54 domidumont joined #moarvm
16:31 TimToady joined #moarvm
16:48 domidumont joined #moarvm
17:50 zakharyas joined #moarvm
20:22 sivoais joined #moarvm
21:27 Ven_ joined #moarvm
21:32 sivoais joined #moarvm
21:57 Ven_ joined #moarvm
22:15 Ven_ joined #moarvm
22:29 Ven_ joined #moarvm
22:41 Ven_ joined #moarvm
22:53 Ven_ joined #moarvm
23:27 Ven_ joined #moarvm

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