Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2015-01-14

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

All times shown according to UTC.

Time Nick Message
00:14 avar joined #moarvm
00:14 avar joined #moarvm
01:02 timotimo joined #moarvm
01:28 dalek joined #moarvm
01:41 timotimo joined #moarvm
02:49 woolfy joined #moarvm
03:00 colomon joined #moarvm
03:20 flussence joined #moarvm
03:24 woolfy joined #moarvm
03:42 timotimo joined #moarvm
04:15 colomon joined #moarvm
07:44 FROGGS joined #moarvm
08:19 kjs_ joined #moarvm
08:31 rurban joined #moarvm
08:48 zakharyas joined #moarvm
09:07 kjs_ joined #moarvm
09:57 moritz joined #moarvm
10:31 kjs_ joined #moarvm
10:36 kjs_ joined #moarvm
11:25 kjs_ joined #moarvm
11:29 kjs_ joined #moarvm
11:56 colomon joined #moarvm
12:18 kjs_ joined #moarvm
13:09 colomon joined #moarvm
14:04 ggoebel111111117 joined #moarvm
14:59 brrt joined #moarvm
15:39 brrt` joined #moarvm
16:51 rurban joined #moarvm
16:56 kjs_ joined #moarvm
16:59 FROGGS joined #moarvm
17:39 rurban joined #moarvm
18:09 tgt joined #moarvm
18:13 FROGGS_ joined #moarvm
20:05 jnthn http://danluu.com/new-cpu-features/ is a kinda interesting read, except I'm a bit full of cold to concentrate long enough to read it all the way through right now...
20:10 brrt joined #moarvm
20:16 zakharyas joined #moarvm
20:34 * nwc10 is reading it a bit rapidly. It references http://www-plan.cs.colorado.edu/klipto/mytkowicz-asplos09.pdf which used perlbench. Yay!
20:34 nwc10 (and many other things)
20:35 nwc10 (significance that I remain curious about is "why does link order affect speed?" - I found this even when I forced all code generation options to align with L1 cache lines)
20:38 kjs_ joined #moarvm
20:45 brrt interesting article
21:02 brrt joined #moarvm
21:22 brrt jnthn, you mean the pointer to the how obj in the spesh slot will be updated if / when the how obj is relocated?
21:22 jnthn brrt: Yes.
21:22 brrt oh, awesome
21:22 jnthn brrt: The GC visits spesh slots.
21:27 timotimo that's neat
21:27 timotimo so having a pointer as a spesh slot is the way to go
21:27 timotimo i seem to recall i had wanted something like an object literal that i could just load into an object register
21:27 timotimo but it seems like spesh slot would be much more sensible
21:28 jnthn Object literals are basically what spesh slots exist for :)
21:28 jnthn "I resolved this thingy and want to make it easy to grab"
21:29 kjs_ joined #moarvm
21:31 timotimo i thought spesh slots were something that code could, in the future, put some value into to reference later; kind of like for caches
21:32 jnthn It can be used for that too
21:32 jnthn And actually they are MVMCollectable *
21:32 jnthn So you can safely stick an STable in 'em too
21:40 brrt jit sometimes puts raw pointers into the bytecode
21:40 brrt which, i'm told, is pretty evil
21:40 jnthn Yes, that *does* need guarding with gen2
21:40 brrt hmm
21:40 timotimo so if you have a cached value, it definitely has to be boxed. good to know
21:40 brrt now that i think of it, i can probably do better than that
21:45 brrt if i ever figure out how to make separate sections with dynasm
21:45 brrt linus doesn't like cmov it appears: http://yarchive.net/comp/linux/cmov.html
21:49 timotimo one more thing i've been thinking about or worried about:
21:49 timotimo if we don't make the deoptimization strategy from jit code to other code better, we won't be able to really get away from loads before instruction, code for instruction, stores after instruction
21:49 timotimo because we need to have the data in the WORK at the points where we deoptimize
21:50 jnthn I don't know there's a problem with the strategy. You statically know where deopt can happen.
21:51 jnthn It's not like absolutely any place can trigger it.
21:51 jnthn And between those points, cheating on WORK is just fine.
21:51 jnthn Conditionally writing back to WORK only if deopt happens is also legit.
21:52 timotimo oh
21:52 timotimo well, that does sound helpful
21:52 jnthn WORK only has to be in good enough shape at the point deopt actually happens, if it happens.
21:52 timotimo would we have a section in the assembly code for each deopt point that knows what registers need to be put into what WORK slots?
21:53 jnthn That's a possible strategy, yes
21:53 timotimo since if we do that inside the deopt function that the C compiler builds, we'll most probably lose register content
21:53 jnthn Could even emit it at the end of the JITted output and branch to it, rather than jump over it, if we want to avoid some branches and clutter the I-Cache for never-hit deopts less.
21:53 brrt you'll have to be conservative in WORK writing anyway because of gc barriers
21:54 jnthn Writes to WORK aren't barriered :)
21:54 jnthn 'cus MVMFrame is not an MVMCollectable
21:54 brrt yeah timo, that's impossible
21:54 timotimo please explain the "end of the JITted output"?
21:54 jnthn timotimo: As in
21:54 timotimo i was thinking we'd be putting all the deopt "bridges" at the end anyway
21:54 jnthn blah blah machine code blah
21:54 timotimo not directly after the deopt point
21:54 brrt i mean not barriers. but anytime you may trigger gc, you need to write to WORK
21:54 jnthn if guard_failed goto deopt_42
21:54 timotimo i'm hoping deopt is rare :)
21:55 jnthn blah blah more code
21:55 brrt and anyway, that's all future
21:55 jnthn ...end of normal code...
21:55 jnthn deopt_42:
21:55 jnthn ...code to get WORK in order...
21:55 timotimo right, that's what i had in mind, too
21:55 * brrt nods, that's basically how i want to do it
21:55 timotimo great
21:55 timotimo we are all in agreement in that case
21:55 brrt but keep in mind you also need to do this in the case of invokes
21:55 jnthn brrt: Yes, that's true. But we should be able to have a good idea when that can happen.
21:55 timotimo right, we already have invoke guards anyway
21:55 jnthn Yes, invokes are also deopt points.
21:55 timotimo and probably also invokish guards?
21:55 timotimo ah, good.
21:56 jnthn OTOH, for small invoked things, we can inline, and then the invoke is gone.
21:56 timotimo but in case of invocations we'd have to tidy up WORK before the invocation?
21:56 brrt and for c callouts (except for callee-save register, but i've already filled them)
21:56 timotimo right, that's something spesh could do before the jit even triggers
21:56 jnthn Yes, WORK'd need syncing before it
21:56 jnthn Spesh already handles inline before JIT triggers. :)
21:57 jnthn Anyway, I think we have a reasonable amount of wiggle room.
21:57 brrt this is a problem common to all JITs I know of
21:58 jnthn Well, it's the cost of speculative optimization: you gotta deal with having speculated wrongly.
21:58 timotimo oh, i meant to write "would", not "could"
21:58 timotimo actually "will"
21:59 brrt my roadmap was as follows
22:00 brrt - first add register selection to x64 dynasm
22:01 brrt - then write a pretty much separate expression compiler
22:01 brrt - i think expressions should be pretty simple in order to be sufficiently generic?
22:01 brrt - then add an expression as a node to the jit graph
22:02 brrt - do writeouts whenever we 'leave' the expression
22:02 brrt so you'd have a sequence: callout, expression, callout, expression, invoke
22:03 brrt ultimately, add more and more jit nodes into the expression compiler
22:03 brrt how to do all this? i don't know yet exactly
22:03 timotimo oh?
22:03 timotimo i thought the SSA form was sufficiently expressiony to work like that
22:03 timotimo but what do i know :)
22:03 timotimo you're the expert for a reason :)
22:04 jnthn brrt: GSoC 2015? :D ;)
22:04 brrt hardly an expert :-)
22:04 timotimo hear hear
22:04 brrt well... i'm certainly not against it :-)
22:04 brrt (wrt to SSA: it /is/ but it is for expressions on the moarvm level)
22:05 jnthn Or I suspect alternative funding can be found if that fails. It'd be a significant and valuable piece of work.
22:06 brrt well.. we'll discuss it when the time comes :-)
22:06 timotimo i'm apparently not close enough to the material to understand the need for the expression compiler
22:06 timotimo but i very much do understand what we need register selection for
22:06 brrt the expession compiler is a term  i made up for the idea that i have about it
22:06 brrt it probably has another name
22:08 brrt the main point of it is to put the load / stores / operations that are done in a tree so we can perform CSE on it
22:08 brrt you can't really do that at moarvm level since it doesn't have this concept of load/stores
22:08 timotimo ah, ok
22:08 timotimo you want to reify loads and stores :)
22:08 brrt you /can/ build such a tree from the ssa form
22:08 brrt and other things
22:08 brrt conditionals and tests
22:10 brrt the dynasm input could be used as a template then
22:11 brrt (but i'm not sure i'm making sense now)
22:29 brrt lua is funky, btw
22:30 hoelzro it *does* part the fun in funky
22:42 kjs_ joined #moarvm
22:42 colomon joined #moarvm
22:50 brrt part or put?
22:50 brrt anyway, startrek& :-)
23:31 retupmoca joined #moarvm

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