07:41 FROGGS[mobile] joined 07:48 rurban joined 07:54 FROGGS joined 08:04 zakharyas joined 08:08 vendethiel joined 09:32 vendethiel joined 09:58 JimmyZ joined 12:33 colomon joined 13:17 vendethiel joined 13:51 vendethiel joined 13:59 FROGGS joined 14:41 dalek joined 15:04 vendethiel joined 15:37 vendethiel joined 16:39 vendethiel joined 16:54 rurban joined 18:13 FROGGS_ joined 19:21 lizmat joined 21:05 brrt joined 21:09 brrt joined
brrt hmm... anybody awake to discuss stuff on the moarvm roadmap? 21:44
jnthn Well, for the "concious" definition of... :)
brrt concious enough to type, which is good enough for me
i have two questions 21:45
or more than two
jnthn ...
:)
Well, that means you have >= 2 I guess :)
brrt a - how badly do we want x86 JIT, because frankly it seems like a huge pain
timotimo nah, that can wait
a long time, IMO
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.
brrt neither have i. but it is on the list
jnthn Yeah, though near the bottom :)
And the ordering is a hand-wavey prioritization.
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?
hmm, i see how that could work
jnthn Good question. I don't know.
brrt: Yes, that's exactly what I mean. I did the 6model design so we could de-virtualize that from the start.
brrt in fact that should be pretty easy 21:48
jnthn brrt: Just didn't actually do it yet.
nwc10 my assumption is "approximately zero" (at least, "approximately zero that are interesting")
jnthn brrt: I don't think it's hard to do, and it could be a rather nice speed-up.
Certainly it's easier on the branch predictor.
brrt nwc10 - that is my assumption too. atoms from a few years ago - my infamous eee pc - support x86_64
jnthn Since it's, well, an unconditional branch to a known address :)
brrt nods 21:49
jnthn A memory access or two less also
Anyway, if you're interested in taking it on - go for it. :)
brrt i'll check it out
jnthn I'm happy enough to have x86 JIT tossed from the roadmap if we don't see value in it. 21:50
I had assumed there'd be some value, but I hadn't really thought it through too much.
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
timotimo that sounds like a nice thing to have
ah, right
jnthn That's how attribute access and so forth goes.
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
it does the spesh_codegen before even starting the jit stuff
oh, actually 21:53
i think i know what to do
brrt i... think the jit somehwat relies on the spesh codegen, but i'm not eniterly sure
jnthn timotimo: Yes, I mentioned that order may need reversing 21:54
timotimo i don't remember reading that, but now it makes sense
jnthn brrt: Yes, the somewhat is what I suggested timotimo++ may be able to identify (if it exists) and mebbe rectify.
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
a shorter roadmap that gets delivered feels better
but I'm (half) asleep, so may not be rational.
and it's not *my* roadmap.
jnthn nwc10: Good points, thanks. 21:58
brrt i do agree on the shorter roadmap idea though
jnthn I'm tempted to not put either on until I actually hear folks wanting 'em.
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
jnthn At least ARMs have, like, some registers, though, so yeah, less pain than x86 I guess :)
nwc10 me neither. Are we really going to land on phones?
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
ie, it might end up that 2 ARM JITs are "needed"
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
(and 64 bit floating points, though these go to a different set of registers)
jnthn yeah, I kinda hedged on 64-bit being the common case. 22:02
brrt imho correctly 22:03
nwc10 I think so too 22:04
timotimo hmm 22:05
in osr_finalize i end up with a candidate where sg is a null pointer 22:06
i wonder how i did that
dalek href="https://moarvm.org:">moarvm.org: 3a2d633 | jnthn++ | roadmap.html:
Toss x85 JIT from the roadmap.

There's not been much in the way of requests for it, and it's likely to be of decreasing interest.
timotimo x85? that sounds difficult
jnthn FAIL 22:08
Apparently I shoulda gone to bed :P
FROGGS jnthn is probably born in x85.... am I right? 22:09
jnthn Yes :)
FROGGS you youngster :P
timotimo well, at least simply reordering jit and bytecde generation doesn't hurt 22:10
brrt timotimo - that surprises me 22:11
jnthn FROGGS: Yeah, though leaving my 20s behind in not long now :P 22:12
FROGGS /o\
jnthn timotimo: How extensively did you test that? :)
timotimo er
i ran a single test file :)
jnthn mebbe try something longer running :P 22:13
timotimo spectesting now
oh
yeah, that hurts
brrt :-)
good 22:14
timotimo gdb is giving me a completely busted stack
brrt it only looks that way 22:15
timotimo gee, thanks, that makes it better :)
brrt the first... 120 bytes or so, are JIT frame stack space
so to gdb that looks like garbage 22:16
doesn't necessarily mean you're completely off track
what do you get if you do x/5i %rip
jnthn
.oO( 5i? our stack pointers are *complex*?! :D )
timotimo :D 22:17
syntax error, brrt
jnthn How does it hurt, ooc? SEGV?
timotimo it doesn't like %rip
yes, segv
brrt i think that means examine %rip as 5 instructions 22:18
jnthn Null pointer, or nasty pointer?
brrt it's should be $rip then timotimo :-) 22:20
timotimo ah 22:21
=> 0x200:Cannot access memory at address 0x200
brrt oh btw, in src/spesh/codegen.c:209, i do think that exception_throw_adhoc should be panic
then we've jumped to there?
timotimo i think i'm already going to bed
brrt timotimo: can you do: print $rip 22:22
the stack should have a good idea
timotimo $1 = (void (*)()) 0x200
brrt ah
timotimo actually
perhaps that's because i "frame 0" 22:23
and i don't know how to reset that, but i can re-run
actually, frame 0 is the "default" state apparently
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
timotimo probably
brrt 'spesh crashed' - oh, but i caught it
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
s/the/they/
timotimo sometimes i'm jealous of KeyboardInterrupt
but at other times i'm glad we don't have that
jnthn brrt: Yeah, they're mostly that way 'cus the stack info can be useful 22:25
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:26
brrt fair point 22:27
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)
aye. but thats beyond what i want to achieve today 22:29
jnthn *nod*
brrt hmm.... timotimo, are you still awake? 22:31
i know of one way to jump into somewhere strange
there is an unconditional variable jump in the prologue of the jit
that would explain some things 22:32
jnthn gets some rest 22:34
'night
brrt good night :-) 22:35
timotimo meep meep
brrt timotimo - your problem is OSR, i think 22:48
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
src/spesh/codegen.c:105
actually, that same thing is true for all deopt idxs
ok, please be so kind to check src/spesh/deopt.c:233-257 22:53
22:53 rurban joined
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:54
the jit relies on the spesh-made mechanisms to do uninline magic 22:55
(and tbh, if jnthn++ hadn't implemented inlining / uninlining, i would certainly have never gotten arround to it)
23:21 betterworld joined, [Coke] joined 23:22 tadzik joined 23:23 pyrimidine joined 23:50 brrt left 23:56 avar 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!