Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2016-02-12

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

All times shown according to UTC.

Time Nick Message
02:09 cognominal joined #moarvm
03:30 colomon joined #moarvm
03:47 japhb joined #moarvm
05:10 flaviusb joined #moarvm
07:25 domidumont joined #moarvm
07:32 domidumont joined #moarvm
07:42 FROGGS joined #moarvm
09:43 leont joined #moarvm
09:47 brrt joined #moarvm
09:47 brrt good * #moarvm
10:14 timotimo good brrt, brrt :)
10:26 brrt good timotimo, timotimo
10:27 brrt hey, good news, i hope to have finished my thesis report, or at least the first draft of it, by the end of this week; meaning that yes, i'll finally have some #moarvm time then :-)
10:27 jnthn \o/
10:31 FROGGS \O7
10:31 FROGGS err
10:31 FROGGS \o/
10:31 FROGGS such excited
10:34 timotimo ooooooooh
10:46 brrt :-)
10:46 brrt yeah, i'll be happy to start working on a real register allocator
10:46 brrt will still be slowish, but more than currently
10:47 timotimo not more slowish, though?
10:57 brrt hopefully
10:57 timotimo :D
10:57 brrt nah, stuff is way to exciting to let lie so long
10:57 timotimo well, our time spent in spesh and jit is superbly small in all the code i've run so far
10:57 brrt oh, i meant *my* progress, not the jits speed
10:58 timotimo oh!
10:58 brrt it should be
10:58 * timotimo re-parses the discussion
10:59 brrt thinking ahead of time, as i usually do, i'm wondering how we can string together multiple expression trees / basic blocks to form loops which we can compile together
10:59 brrt hmmm
10:59 brrt well,
11:00 brrt when put that way
11:00 brrt shouldn't be all that hard
11:00 brrt we 'just' create a MVMJitExprLoop structure to contain the relevant basic blocks, and we run register allocation on the whole set
11:00 timotimo it seems to me like you get a lot of mileage out of "rubber duck design"
11:00 brrt i do, yes :-)
11:01 timotimo if we have such a loop structure, that may be an interesting cornerstone for doing loop-invariant code motion and such?
11:01 brrt i mean, it's loops we care most about
11:01 brrt hmmm... yes, to a degree
11:01 brrt although, i'd argue, we prefer.. that to be done in spesh
11:01 brrt hey, that *would* be a good idea
11:02 brrt question
11:02 brrt would this be hard to implement in spesh
11:02 jnthn Only to the degree it's hard to implement anyway :)
11:02 timotimo fair enough
11:03 timotimo it's bothering me that i haven't started work on the deopt bridges stuff, but it's not bothering me enough to make me start work on it
11:04 timotimo i've thought about adding a little bit of analysis for how useful that could be, but it seemed like adding just that analysis would already be three quarters of the actual implementation ...
11:05 timotimo anyway, what's keeping spesh from kicking performance butt at the moment is, in my opinion, that we fail to inline a significant number of cases. and if there's lexicalrefs/localrefs involved, it straight up won't try
11:06 brrt if you need any motiviation, you have my assurance that deopt bridges will pay themselves handsomely in many cases, *especially* once the JIT becomes smarter
11:06 brrt and especially-er if/when we start doing trace compilation
11:06 brrt but yeah, that might probably be an even more directly relevant bit :-)
11:07 timotimo there's also some things i'm worried about related to lifecycle management
11:07 timotimo as in: i'd like spesh to run over the same piece of code multiple times in some cases
11:07 timotimo imagine a frame with multiple loops. the first loop is super simple, the other two not so much
11:07 timotimo OSR kicks in, adds a logging phase, but only the log instructions in the first loop ever get hit
11:08 timotimo then it's satisfied with the result and never touches that frame again, because the osrpoint instructions get kicked out (and i don't know if spesh won't get horribly confused if it hits osrpoints in an already-speshed frame)
11:08 jnthn I think we'll probably restructure things somewhat
11:08 timotimo i'm all ears (and a tiny amount of brain, too)
11:08 jnthn Around the same time spesh gets kicked off to run on a background thread
11:09 jnthn I'd like to do something closer to PICs that collect data over time
11:09 timotimo PIC? i only know that acronym from the microprocessor company
11:09 jnthn Polymorphic Inline Cache
11:09 timotimo ah
11:09 jnthn They're an interpreter optimization but more usefully you can look at the data they collected
11:10 jnthn So you get stats
11:10 timotimo oh, yes, i'd like to see that kind of thing :D
11:11 timotimo say, i read recently that moar lets nursery collections happen individually per thread without stopping other threads, is that true?
11:12 jnthn No
11:12 jnthn Only finalization is concurrent
11:13 jnthn We'll likely shove that off to a background thread also to cut down our overall pause times
11:13 timotimo right
11:21 brrt fwiw, spesh allocation is still awesome
11:21 brrt it's the open-bar-party version of allocation
11:22 brrt take as much as you need, and somebody else pays for it, who doesn't want that
11:22 timotimo hm. will a polymorphic inline cache be just a bunch of data in the instruction stream and an instruction in front that says "jump over this many bytes"?
11:22 jnthn brrt: You, the next morning? :P
11:22 timotimo jnthn: that'd be more than "as much as you need"
11:22 timotimo probably
11:22 jnthn Ah, point :P
11:23 brrt true enough
11:23 brrt maybe i should have said, 'as much as you want'
11:27 brrt still, it is a pleasant experience after mucking about with malloc/calloc/free
11:31 jnthn Yeah, unsurprisingly there were not many spesh related leaks :)
11:32 jnthn (They were all about leaks of things that remain after we specialized)
11:32 brrt yeah, like the jitcode things
11:32 brrt i should merge that into even-moar-jit
12:11 FROGGS joined #moarvm
12:26 khagan joined #moarvm
12:51 domidumont joined #moarvm
14:37 dalek MoarVM: 3a38749 | timotimo++ | src/core/interp.c:
14:37 dalek MoarVM: check for NULL in exception payload and return VMNull in getexpayload
14:37 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/3a387495d9
17:02 domidumont joined #moarvm
17:43 leont joined #moarvm
18:08 ggoebel16 joined #moarvm
18:50 FROGGS joined #moarvm
19:01 domidumont1 joined #moarvm
19:18 leont joined #moarvm
20:07 brrt joined #moarvm
20:28 diakopter timotimo: probably also investigate how the payload could be NULL instead of VMNull?
20:41 timotimo creating a vmexception without setting the payload, obviously ;)
20:46 [Coke] joined #moarvm
21:58 brrt joined #moarvm

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