Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2014-04-27

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

All times shown according to UTC.

Time Nick Message
01:17 FROGGS_ joined #moarvm
07:53 woolfy left #moarvm
07:54 woolfy joined #moarvm
11:54 FROGGS joined #moarvm
13:16 brrt joined #moarvm
13:17 brrt hi #moarvm
13:18 timotimo hey brrt
13:18 timotimo i see you've started introducing yourself :)
13:18 brrt i have
13:22 brrt i think my original plan will have to be edited somewhat
13:23 brrt since the first month or so has been made redundant by spesh
13:24 timotimo heh.
13:24 timotimo well, spesh can use a few more touch-ups anyway
13:25 timotimo as soon as jnthn has a design for introducing extra registers and stuff, we'll be able to build more optimizations
13:25 brrt ...
13:25 brrt hmmm
13:25 timotimo otherwise, feel free to use the time to practice with dynasm instead
13:25 brrt i should talk to jnthn about taht
13:25 timotimo or to build a lua compiler + runtime to make the lua compile-time dependency irrelevant :P
13:30 zakharyas joined #moarvm
13:35 FROGGS brrt: it would not hurt if you still follow the goals and perhaps finish early and do extra stuff then :o)
13:36 brrt i think the goals are the same :-)
13:37 brrt (brb)
14:00 brrt joined #moarvm
14:01 brrt but, wait, introducing new registers
14:03 brrt at first sight, that seems at odds with jit compilation
14:06 timotimo well, it would happen before the jit would kick in
14:06 timotimo during spesh, that is
14:07 timotimo and it would have to create a proper CFG plus dominance and SSA anyway
14:07 timotimo so the input to the jit stage wouldn't be distinguishable from regular data
14:08 timotimo of course we'd have to be careful around deopt spots
14:08 timotimo but IMO it's a necessary step towards better optimizations
14:09 timotimo for example, an isstr, isnum, isint, ishash, islist could be turned into a spesh-time-repr-ID-check plus a run-time-null-check
14:09 timotimo but that would require more instructions, because we have a "isnull" op, but we need the negated output from that, so we need to put in an extra negation
14:10 timotimo or we'd have to know the result is only used once, in an if, and turn that into an unless or so.
14:12 brrt hmm i see
14:13 brrt do i understand correctly if this is not so much about introducing new registers to the vm as using more registers in the bytecode?
14:13 timotimo ah, exactly
14:13 timotimo i wasn't being clear :)
14:13 timotimo should have said "allocate more registers"
14:15 brrt phew :-)
14:15 brrt no, thats no problem to me
14:16 timotimo i suppose the problem really is that the first step is going over everything and building the SSA, CFG and dominance
14:16 brrt but spesh does that, right?
14:16 timotimo and if you're in the middle of spesh, you would have to know about global things if you want to twiddle something in the middle
14:16 brrt uhuh
14:16 timotimo spesh does it at the very start, aye
14:17 brrt ok, my mental model of spesh -> jit is such: spesh takes a MVMStaticFrame, computes a CFG etc
14:18 brrt you then have a tree that is supposedly in SSA form, on which you run all sorts of tree-manipulation algorithms
14:18 timotimo currently we mostly do intra-block-changes and then drop any blocks that become entirely irrelevant from the tree
14:18 brrt i can imagine some of these algorithms turning the tree from ssa form to non-ssa form
14:18 timotimo except if you're refering to the SSA as "the tree"
14:19 brrt no, i'm refering to MVMSpechGraph as the tree ;-)
14:19 timotimo OK
14:19 timotimo not very much happening there so far
14:20 brrt anyway, i imagine the MVMSpeshGraph to be input to the JIT compiler
14:20 timotimo that's my understanding as well
14:21 timotimo off the spesh graph hang all the BB's which contain both the instructions and the layout of the tree
14:21 timotimo each BB has a "linear_next" that defines how the BBs will be output to byte code or machine code (as they have to be linearized *some* way)
14:22 timotimo and the predecessors and successors list where control can come from and go to and inside the BB, there are different kinds of goto ops that cause branches
14:23 brrt hmmkay
14:27 brrt moarvm 'registers' are really just offsets from the stack, right?
14:27 timotimo not sure about that, but it sounds likely
14:27 timotimo they are not directly corresponding to machine registers, that much is for sure
14:28 timotimo especially since we can have thousands of them active :)
14:30 brrt i should look it up
14:30 brrt for most people it's an implementation detail, but not for me :-)
14:30 brrt i need to know how to treat them when compiling
14:31 timotimo :)
15:15 jnthn .tell brrt the registers/locals are just a blob of memory hanging off ->work in the current frame. That memory also contians an args buffer.
15:15 timotimo ohai jnthn
15:16 jnthn o/
15:16 timotimo should brrt help you think about a design for the "allocate new registers in the spesh stage" thing?
15:16 jnthn Well, design suggestions are always fine.
15:16 jnthn Just need to be a fairly general mechanism.
15:17 timotimo well, if we're guaranteeing that a newly allocated register is "released" at the end of the changed segment, it should be all right to just ... you know ... "do it"?
15:18 timotimo of course we'll have to make sure the usage counts are there, else the end stage of spesh will just kick them out again :)
15:19 jnthn Well, whatever design we come up with needs to work out nicely with inlining.
15:20 timotimo i haven't thought about inlining at all yet, hmm
15:20 timotimo not exactly sure what it'll end up looking like
15:20 jnthn I've some ideas, but probably the easiest way for me to work the design out is to implemnet it. :)
15:20 timotimo well, i'm looking forward to that :)
15:22 timotimo i'd like to have a look at the code we generate for loops like for @foo Z @bar -> $a, $b { }
15:22 timotimo i may build a few benchmarks to pit that against iterating over an index and grabbing the appropriate item out and seeing how they compare
15:23 timotimo this is an idiom i'd really like to be cheap
15:25 jnthn Well, I suspect it's just infix:<Z>(@foo, @bar).map(-> $a, $b { ... }).eager :)
15:27 jnthn probably bbl &
15:33 timotimo and does the map do clever things?
16:02 FROGGS jnthn: I have a question: should int be int32 on x86 platforms in perl6?
16:25 FROGGS jnthn: nvm :o)
16:41 FROGGS in nativecall.c
16:41 FROGGS else if (strcmp(cname, "stdcall") == 0)
16:41 FROGGS result = DC_CALL_C_X86_WIN32_STD;
16:41 FROGGS else if (strcmp(cname, "stdcall") == 0)
16:41 FROGGS result = DC_CALL_C_X64_WIN64;
16:41 FROGGS that does not make much sense, does it?
16:48 timotimo yeah, that doesn't seem right
16:55 FROGGS I think the second should be more like x64Win
16:55 timotimo well that second branch is certainly dead at the moment
16:56 FROGGS sure it is
16:56 timotimo so i suppose giving "x64win" a try for the cname wouldn't make it much worse, would it?
16:58 FROGGS ohh, in nqp/vm/parrot it is called "win64"
17:00 FROGGS hmmm, one can set the calling convention using the role NativeCallingConvention
17:00 FROGGS dunno if someone really does so
19:08 zakharyas joined #moarvm
20:16 jnap joined #moarvm
20:26 dalek joined #moarvm
20:58 jnthn FROGGS: No, int probably wants to keep its Perl 6 meaning. I'd pondered introducing cint types that we export aliased to int32 or whatever.
20:58 timotimo that would be at least trivial to put into the setting, no?
20:58 jnthn No, in NativeCall
21:02 timotimo er, yes
21:08 btyler joined #moarvm
23:11 jnap joined #moarvm
23:36 lue joined #moarvm
23:36 timotimo pretend i'd have put the stuff about uthash here instead of in #perl6

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