Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2015-01-06

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

All times shown according to UTC.

Time Nick Message
07:41 FROGGS[mobile] joined #moarvm
07:48 rurban joined #moarvm
07:54 FROGGS joined #moarvm
08:04 zakharyas joined #moarvm
08:08 vendethiel joined #moarvm
09:32 vendethiel joined #moarvm
09:58 JimmyZ joined #moarvm
12:33 colomon joined #moarvm
13:17 vendethiel joined #moarvm
13:51 vendethiel joined #moarvm
13:59 FROGGS joined #moarvm
14:41 dalek joined #moarvm
15:04 vendethiel joined #moarvm
15:37 vendethiel joined #moarvm
16:39 vendethiel joined #moarvm
16:54 rurban joined #moarvm
18:13 FROGGS_ joined #moarvm
19:21 lizmat joined #moarvm
21:05 brrt joined #moarvm
21:09 brrt joined #moarvm
21:44 brrt hmm... anybody awake to discuss stuff on the moarvm roadmap?
21:44 jnthn Well, for the "concious" definition of... :)
21:44 brrt concious enough to type, which is good enough for me
21:45 brrt i have two questions
21:45 brrt or more than two
21:45 jnthn ...
21:45 jnthn :)
21:45 jnthn Well, that means you have >= 2 I guess :)
21:45 brrt a - how badly do we want x86 JIT, because frankly it seems like a huge pain
21:45 timotimo nah, that can wait
21:45 timotimo a long time, IMO
21:46 timotimo ARM jit, on the other hand, could become interesting sooner than x86 jit
21:46 jnthn I don't know. I haven't heard huge demand for it yet.
21:46 brrt neither have i. but it is on the list
21:46 jnthn Yeah, though near the bottom :)
21:46 jnthn And the ordering is a hand-wavey prioritization.
21:47 nwc10 How many new products (and prodcut categories) are on x86 (and not x86_64)?
21:47 brrt anyway... about the repr operrations, do we mean to say that repr operations on known types can resolve to the function?
21:47 brrt hmm, i see how that could work
21:47 jnthn Good question. I don't know.
21:47 jnthn brrt: Yes, that's exactly what I mean. I did the 6model design so we could de-virtualize that from the start.
21:48 brrt in fact that should be pretty easy
21:48 jnthn brrt: Just didn't actually do it yet.
21:48 nwc10 my assumption is "approximately zero" (at least, "approximately zero that are interesting")
21:48 jnthn brrt: I don't think it's hard to do, and it could be a rather nice speed-up.
21:48 jnthn Certainly it's easier on the branch predictor.
21:48 brrt nwc10 - that is my assumption too. atoms from a few years ago - my infamous eee pc - support x86_64
21:48 jnthn Since it's, well, an unconditional branch to a known address :)
21:49 * brrt nods
21:49 jnthn A memory access or two less also
21:49 jnthn Anyway, if you're interested in taking it on - go for it. :)
21:49 brrt i'll check it out
21:50 jnthn I'm happy enough to have x86 JIT tossed from the roadmap if we don't see value in it.
21:50 jnthn I had assumed there'd be some value, but I hadn't really thought it through too much.
21:51 timotimo i thought we were already devirtualizing REPR ops o_O
21:51 jnthn timotimo: Well, in some special cases they go away entirely in favor of spesh ops, which then JIT nicely
21:51 timotimo that sounds like a nice thing to have
21:51 timotimo ah, right
21:51 jnthn That's how attribute access and so forth goes.
21:52 jnthn But that still leaves the hash/array indexy ones.
21:52 timotimo jnthn: i'm not entirely sure how to remove the spesh codegen from the candidate thing
21:52 timotimo it does the spesh_codegen before even starting the jit stuff
21:53 timotimo oh, actually
21:53 timotimo i think i know what to do
21:53 brrt i... think the jit somehwat relies on the spesh codegen, but i'm not eniterly sure
21:54 jnthn timotimo: Yes, I mentioned that order may need reversing
21:54 timotimo i don't remember reading that, but now it makes sense
21:54 jnthn brrt: Yes, the somewhat is what I suggested timotimo++ may be able to identify (if it exists) and mebbe rectify.
21:57 nwc10 jnthn: it's easy to put stuff back onto the roadmap, if someone sees merit in it. But I suspect that for expectation management/suggestions for contributions/GSoC/similar, just having "ARM JIT" is more useful than both "x86 JIT" and "ARM JIT"
21:57 nwc10 a shorter roadmap that gets delivered feels better
21:57 nwc10 but I'm (half) asleep, so may not be rational.
21:57 nwc10 and it's not *my* roadmap.
21:58 jnthn nwc10: Good points, thanks.
21:58 brrt i do agree on the shorter roadmap idea though
21:58 jnthn I'm tempted to not put either on until I actually hear folks wanting 'em.
21:59 jnthn As in, I agree ARM may be more strategic, but I dunno how big our potential userbase is there either.
21:59 nwc10 yes, probably a good plan
21:59 jnthn At least ARMs have, like, some registers, though, so yeah, less pain than x86 I guess :)
21:59 nwc10 me neither. Are we really going to land on phones?
22:00 brrt who said anything about phones. i want perl6-on-gameboy advance :-P
22:00 nwc10 I don't know how different the upcoming 64 bit ARM is to JIT, compared with the current 32 bit
22:00 nwc10 ie, it might end up that 2 ARM JITs are "needed"
22:01 nwc10 or that somepoint soon-ish, the interesting ARM based targets are v8 (64 bit), but our hypothetical JIT is 32 bit, so not (so) useful
22:01 brrt the great thing about 64 bit anything is that we use 64 bit integers throughout moarvm, and having actual 64 registers makes that easy
22:01 brrt (and 64 bit floating points, though these go to a different set of registers)
22:02 jnthn yeah, I kinda hedged on 64-bit being the common case.
22:03 brrt imho correctly
22:04 nwc10 I think so too
22:05 timotimo hmm
22:06 timotimo in osr_finalize i end up with a candidate where sg is a null pointer
22:06 timotimo i wonder how i did that
22:06 dalek moarvm.org: 3a2d633 | jnthn++ | roadmap.html:
22:06 dalek moarvm.org: Toss x85 JIT from the roadmap.
22:06 dalek moarvm.org:
22:06 dalek moarvm.org: There's not been much in the way of requests for it, and it's likely to
22:06 dalek moarvm.org: be of decreasing interest.
22:06 dalek moarvm.org: review: https://github.com/MoarVM/moarvm.org/commit/3a2d6337e6
22:06 timotimo x85? that sounds difficult
22:08 jnthn FAIL
22:08 jnthn Apparently I shoulda gone to bed :P
22:09 FROGGS jnthn is probably born in x85.... am I right?
22:09 jnthn Yes :)
22:09 FROGGS you youngster :P
22:10 timotimo well, at least simply reordering jit and bytecde generation doesn't hurt
22:11 brrt timotimo - that surprises me
22:12 jnthn FROGGS: Yeah, though leaving my 20s behind in not long now :P
22:12 FROGGS /o\
22:12 jnthn timotimo: How extensively did you test that? :)
22:12 timotimo er
22:12 timotimo i ran a single test file :)
22:13 jnthn mebbe try something longer running :P
22:13 timotimo spectesting now
22:13 timotimo oh
22:13 timotimo yeah, that hurts
22:13 brrt :-)
22:14 brrt good
22:14 timotimo gdb is giving me a completely busted stack
22:15 brrt it only looks that way
22:15 timotimo gee, thanks, that makes it better :)
22:15 brrt the first... 120 bytes or so, are JIT frame stack space
22:16 brrt so to gdb that looks like garbage
22:16 brrt doesn't necessarily mean you're completely off track
22:16 brrt what do you get if you do x/5i %rip
22:16 jnthn .oO( 5i? our stack pointers are *complex*?! :D )
22:17 timotimo :D
22:17 timotimo syntax error, brrt
22:17 jnthn How does it hurt, ooc? SEGV?
22:17 timotimo it doesn't like %rip
22:17 timotimo yes, segv
22:18 brrt i think that means examine %rip as 5 instructions
22:18 jnthn Null pointer, or nasty pointer?
22:20 brrt it's should be $rip then timotimo :-)
22:21 timotimo ah
22:21 timotimo => 0x200:Cannot access memory at address 0x200
22:21 brrt oh btw, in src/spesh/codegen.c:209, i do think that exception_throw_adhoc should be panic
22:21 brrt then we've jumped to there?
22:21 timotimo i think i'm already going to bed
22:22 brrt timotimo: can you do: print $rip
22:22 brrt the stack should have a good idea
22:22 timotimo $1 = (void (*)()) 0x200
22:22 brrt ah
22:22 timotimo actually
22:23 timotimo perhaps that's because i "frame 0"
22:23 timotimo and i don't know how to reset that, but i can re-run
22:23 timotimo actually, frame 0 is the "default" state apparently
22:23 brrt in fact i'd argue that all the adhoc exceptions in spesh should be panics, because adhoc exceptions can be caught, and that'd be silly
22:23 timotimo probably
22:23 brrt 'spesh crashed' - oh, but i caught it
22:24 timotimo it's kind of like python programs that don't expect KeyboardInterrupt exceptions coming from literally any single line of code
22:24 brrt as the bloody well shouldn't, but that's another manner
22:24 brrt s/the/they/
22:24 timotimo sometimes i'm jealous of KeyboardInterrupt
22:24 timotimo but at other times i'm glad we don't have that
22:25 jnthn brrt: Yeah, they're mostly that way 'cus the stack info can be useful
22:26 jnthn brrt: I think we may want to differentiate panic when we know we're hosed and can't even try to dump out where we were, and panic when we probably haven't trashed the VM state and so can try to produce some info on where we were.
22:27 brrt fair point
22:28 jnthn Generally, the frame on the stack top is the one we're speshing, which is useful to know.
22:28 brrt (wrt to KeyboardInterrupt - funny how a broken pipe signal doesn't do that)
22:29 brrt aye. but thats beyond what i want to achieve today
22:29 jnthn *nod*
22:31 brrt hmm.... timotimo, are you still awake?
22:31 brrt i know of one way to jump into somewhere strange
22:31 brrt there is an unconditional variable jump in the prologue of the jit
22:32 brrt that would explain some things
22:34 * jnthn gets some rest
22:34 jnthn 'night
22:35 brrt good night :-)
22:35 timotimo meep meep
22:48 brrt timotimo - your problem is OSR, i think
22:50 brrt long story short, during OSR we jump from a normal frame to a spesh frame, and to do that we look up the current bytecode index during spesh codegen
22:50 brrt src/spesh/codegen.c:105
22:50 brrt actually, that same thing is true for all deopt idxs
22:53 brrt ok, please be so kind to check src/spesh/deopt.c:233-257
22:53 rurban joined #moarvm
22:54 brrt basically, we can't uninline without a table for bytecode offsets of the respective inlines, and this table isn't generated until, well, spesh codegen
22:55 brrt the jit relies on the spesh-made mechanisms to do uninline magic
22:55 brrt (and tbh, if jnthn++ hadn't implemented inlining / uninlining,  i would certainly have never gotten arround to it)
23:21 betterworld joined #moarvm
23:21 [Coke] joined #moarvm
23:22 tadzik joined #moarvm
23:23 pyrimidine joined #moarvm
23:50 brrt left #moarvm
23:56 avar joined #moarvm
23:56 avar joined #moarvm

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