Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2015-05-21

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

All times shown according to UTC.

Time Nick Message
01:27 vendethiel joined #moarvm
03:17 colomon joined #moarvm
04:51 flaviusb joined #moarvm
06:26 FROGGS joined #moarvm
06:43 arnsholt joined #moarvm
06:43 tadzik joined #moarvm
06:44 camelia joined #moarvm
06:51 ggoebel joined #moarvm
07:09 zakharyas joined #moarvm
07:23 mj41 joined #moarvm
07:28 lizmat joined #moarvm
08:05 vendethiel joined #moarvm
10:55 lizmat joined #moarvm
11:09 mj41 joined #moarvm
11:35 colomon_ joined #moarvm
11:46 retupmoca joined #moarvm
11:46 hoelzro joined #moarvm
12:09 zakharyas joined #moarvm
15:06 Ven joined #moarvm
15:45 FROGGS joined #moarvm
16:22 ingy japhb: tmux' killer feature for shared sessions is auto sizing
16:22 ingy years of screen hate for having to agree on a screen size
16:22 timotimo what does screen do if all attached sessions aren't the right size?
16:23 ingy it just fucks up weirdly
16:23 ingy and we used to do 20 user shared meetings
16:24 timotimo mhm
16:26 ingy other than that I can't really identify anything in tmux that I couldn't do it screen
16:26 ingy though tmux *feels* more well thought out
16:26 ingy but it had screen to set the bar
16:42 japhb Huh.  The version of screen I used to use for those multi-user debugging sessions just shrunk to the smallest attached viewport; people with larger viewports just saw the active screen in the upper left of their viewport.
16:42 japhb Dunno if it was stock or hacked to be that way.
16:44 japhb Yeah, it's much easier to make it look easy when a previous project found all the jagged hard bits.  :-)
16:45 * PerlJam finds it odd that screen is still relevant after all these years.
16:48 japhb PerlJam: Think how long it took to get rid of SysV Init ... oh wait, we still haven't ... >.<
16:53 timotimo we want to make a moarvm release
16:54 timotimo right?
16:54 prammer joined #moarvm
16:55 jepeway joined #moarvm
16:55 PerlJam usually :)
16:57 timotimo ah, now i read that froggs is going to cut the release in ~1.5h
16:59 PerlJam Who can upload release tarballs?  (I kind of assumed FROGGS was on that list)
16:59 FROGGS not for MoarVM
16:59 FROGGS I can upload stuff to rakudo.org
17:03 PerlJam Is it just jnthn then?
17:04 zakharyas joined #moarvm
17:05 PerlJam heh, trolling the logs, it looks like we've had this conversation before
17:25 FROGGS aye
17:27 zakharyas joined #moarvm
17:41 Ven joined #moarvm
17:59 brrt joined #moarvm
17:59 brrt \o
18:00 brrt timotimo - i renember what was the problem with deopt
18:00 brrt deopt is the part that requires the normal spesh codegen for the JIT to work
18:00 brrt because of inlining boundary calculations
18:00 brrt if i recall completely correctly
18:08 dalek MoarVM: e80bd35 | FROGGS++ | docs/ChangeLog:
18:08 dalek MoarVM: add changes for 2015.05 release
18:08 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/e80bd35bb7
18:28 timotimo brrt: please explain?
18:29 timotimo that's a big-ass changelog
18:29 brrt i'll have to grab the code for that
18:29 brrt waitaminute
18:30 brrt very simply put
18:31 brrt at src/spesh/deopt.c line 12, is the definition of uninline
18:31 brrt it takes an argument for the offset in the speshed frame
18:31 brrt this offset is used to determine in which inlines the code is currently
18:32 brrt see line 20 for the relevant comparison
18:33 timotimo OK, but can't i just call it with "the right" value at the end of the bridge, just by taking the value that's "at the beginning" of the bridge (to say: where we branch into the bridge)
18:33 timotimo this is about my question whether or not we can have bridges for deopt inline, yeah?
18:34 brrt oh, you can do that, that'd mean calling MVM_spesh_deopt_one_direct() (i'd think)
18:34 brrt the thing is
18:34 brrt this all requires that spesh does real codegen
18:34 brrt ultimately, that's not what you want
18:34 timotimo it ... does?
18:34 brrt and not what you need
18:34 brrt yes
18:35 timotimo i'm not sure i'm on the same page as you just yet
18:35 brrt you know how you wanted to stop spesh codegen if we already had a JIT frame?
18:35 timotimo ah, yes
18:36 timotimo i wanted to deallocate data from whatever spesh still holds (the spesh graph, iirc)
18:36 brrt if we can JIT, spesh currently generates a): a specialized frame b): a JIT-compiled frame, and c): the frame in a) is *never run*
18:36 timotimo but it had to keep the deopt indices around
18:36 brrt right, and now you know why
18:36 timotimo ah, we jit immediately? we don't even wait for the spesh'd frame to get considered hotter?
18:37 brrt it is because spesh deopt requires a sensible offset to find the current inlined frame
18:37 brrt well, yes, we JIT immediately
18:37 mj41 joined #moarvm
18:37 brrt the JITting is directly hooked into candidate.c
18:38 timotimo OK
18:38 timotimo i'm still not quite sure what your overall target of telling me all this is
18:38 timotimo i suppose i can still build bridges out of code that's outside of inline boundaries
18:39 brrt yes. i don't think that will be the problem either
18:39 brrt my purpose is
18:39 brrt i want that implicit dependency from the JIT to the spesh codegen (of a useless frame) killed
18:40 brrt and i was wondering if you had any ideas how
18:40 timotimo ah
18:40 timotimo no, i don't :(
18:40 brrt hmm
18:40 timotimo i suppose i'm not deep enough into that
18:41 timotimo as it currently stands, i consider the task of building bridges to be quite shallow, actually
18:41 brrt oh really?
18:41 timotimo yes, let me try to outline it
18:41 brrt i'm listening
18:41 timotimo 1) identify variables whose sole reason for being kept around is that it's expected to be available in the deopted code after we maybe deopt
18:42 timotimo 2) identify all the deopt points that keep this value alive (i think this can be multiple deopt points for a single variable)
18:42 timotimo 3) turn the deopt instruction into a guard-or-branch and split up the BB at that point
18:43 timotimo 4) in the target branch of the guard-or-branch, emit a deoptone or deoptall at the end with the correct deopt index/address/whatever
18:43 brrt how do you detect 1)
18:43 brrt and 2)
18:43 brrt doesn't seem so shallow to me
18:43 brrt but continue
18:43 timotimo there's code in the facts that already does it, all we have to do is emit a fact flag (which i have a very short patch for locally)
18:43 brrt arent guards already bb ends?
18:43 timotimo i'm not sure, i don't think so
18:44 brrt hmmn no
18:44 timotimo 5) move everything that only has to be around for deopt reasons into the "bridge" BB
18:44 brrt they should be
18:44 timotimo they don't need to be, but it'd be simpler and my code will end up having to make that be the case anyway
18:44 timotimo 6) maybe successively move more and more stuff into the bridge as more variables are only depended on by code in the bridge
18:44 timotimo 7) profit
18:45 brrt ok
18:45 * brrt likes it
18:45 brrt what if there are no such variables, you just leave it alone?
18:45 timotimo sure, then a bridge doesn't have to be built at all
18:46 brrt i can imagine that can be quite a saving
18:46 timotimo i've seen multiple cases where we emit a spesh'd lookup of a code object instead of asking an object for a named method, but the const_s for the method's name still sicks around because post-deopt code depends on it being there
18:47 timotimo (of course: if the type isn't the same any more, you have to know what method name to look for)
18:47 timotimo but the const_s doesn't belong in the spesh'd code, IMO
18:47 timotimo this kind of thing might also be useful for "allocation sinking" kinds of deals
18:49 * brrt nods
18:49 brrt but const_s isn't really a very large op
18:50 timotimo of course not
18:50 timotimo i hope there's other things that'll fall under this opt :)
18:50 timotimo when we do box/unbox tracking, we may find more stuff that could go into bridges
18:50 timotimo there's also bunches of set instructions that are only there because the original code used to have many registers populated with the same value
18:53 timotimo it'd be nice if we could just make our frames have fewer registers "in use" and "scatter our values around" in case a deopt is needed
18:53 timotimo i wonder how expensive walking the stack for gc roots is
18:54 timotimo were you expecting something else when i talked about deopt bridges in the past?
18:59 brrt no
18:59 brrt but i recall that there was something that i wanted fixed in deopt
19:00 timotimo good, in that case i don't disappoint when i deliver the implementation ... perhaps
19:00 brrt :-)
19:01 timotimo i might disappoint myself if it turns out the effect is negligible
19:01 brrt no
19:01 brrt this in itself might not matter much
19:01 brrt in combination with tracing, it is likely to help much more
19:02 brrt in combination with the improved JIT codegen, this means that a register allocater will have fewer live variables, and thus more values that can be kept in memory
19:02 brrt eh in registers
19:02 brrt that will actually be used
19:03 brrt that is why i think it's awesome
19:04 brrt we get good performance not from one silver bullet but by a large amount of tiny things that combine
19:06 brrt (that is the punchline from my talk on JIT compilers, if i do one, by the way)
19:08 timotimo ok
19:09 timotimo thank you for cheering me on :)
19:09 brrt your welcome :-)
19:09 brrt you're
19:09 brrt ugh
19:10 timotimo sometimes i find it hard to just be happy about the improvements we've made so far and feel a bit sad about how far we are still away from very competitive performance for every-day tasks
19:11 brrt oh, that's not our fault though
19:11 brrt perl6 has evil semantics
19:11 timotimo partially
19:11 brrt i mean, containers? wow
19:11 brrt who thinks up these things
19:12 brrt :-)
19:12 timotimo i'm mostly upset about the lexical-to-local optimization being busted since we got lexicalref
19:12 brrt eh, how come?
19:12 timotimo i expect it's the source of a big amount of BOOTCode allocations
19:13 timotimo it has to lower lexicalref to localref where before it was just turning lexical into local
19:13 timotimo and the code-gen for accessing locals as localref and localrefs as locals is busted
19:13 timotimo quite sadly
19:13 timotimo i wasn't able to fix it up properly :(
19:15 brrt hmm oh yes i recall
19:15 brrt we'll fix it someday
19:16 brrt (another small thing that combines ;-))
19:16 * brrt afk
19:16 timotimo fwiw, i consider this to be huge
19:21 Ven joined #moarvm
19:26 Ven joined #moarvm
19:44 jnthn oh my, today is release day, ain't it...
19:44 FROGGS jnthn: it is :o)
19:44 jnthn grmbl
19:44 FROGGS jnthn: np...
19:44 jnthn OK, did you do any of the release steps already?
19:44 FROGGS jnthn: do we want to do it tomorrow?
19:45 FROGGS I updated the changelog, nothing else
19:45 FROGGS and did testing and stuff of course
19:46 FROGGS tbh, I would like to do it tomorrow, then I have a bunch of hours more of testing
19:46 jnthn I've gotta get up at 6:30am tomorrow, and am still recovering from assorted health fail.
19:46 jnthn So I'm +1 on tomorrow
19:46 FROGGS k :o)
19:46 FROGGS I'll do the release and provide a tarball for you to upload then tomorrow
19:47 jnthn OK, or if you can wait until 11am or so I'll be home
19:47 jnthn And my only task tomorrow is laundry, so I'll certainly have time to do it once hom :)
19:47 jnthn *home
19:47 jnthn Maybe I'll even do some of the steps on the plane
19:48 FROGGS around 11am will work too
19:48 FROGGS I do not expect that we need to touch moarvm at all
19:52 jnthn ok
19:53 brrt joined #moarvm
20:07 brrt jnthn - do you think you'll be at YAPC::EU this year?
20:07 jnthn brrt: Highly likely.
20:08 brrt good :-)
20:08 jnthn brrt: I mean, I fully intend to go, and there's time in my schedule for it.
20:08 jnthn So unless something highly unexpected comes up, I'll be there. :)
20:08 * jnthn will be happy to see Granada again too :)
20:08 brrt nice, i intend to go too, despite it being the wrong month
20:08 brrt have you ever been there?
20:09 jnthn Yeah :)
20:09 brrt photos say its pretty
20:09 jnthn But in a February, when it was about perfect weather for me. :)
20:09 jnthn It *is*. :)
20:09 jnthn Especially the palace there.
20:10 jnthn (February weather in Granada = warm enough I could wear a t-shirt, cool enough I could walk briskly and be comfortable :))
20:10 brrt yeah, i can imagine that
20:10 jnthn I suspect September will be...different. :)
20:11 jnthn It was kinda cool in Feb though, 'cus the mountain visible in the distance from the city had snow on it. But you were wandering around nice and warm :)
20:12 brrt weather sites say it'll be around 24 degrees celsius, which i can live with
20:12 brrt not for birsk walking, though
20:13 brrt *brisk
20:13 jnthn aye
20:15 brrt hmm, i've thought about it some more
20:15 timotimo jnthn: you'll do some of your laudnry on the plane?
20:16 brrt jet laundry
20:16 brrt anyway, about the deopt offset thingy
20:16 timotimo the mile high laundry line
20:16 brrt we only strictly need to know the target offset (in the original bytecode, which you know because annotation)
20:17 brrt and the inline number, if any
20:17 timotimo yeah
20:17 brrt hmm
20:17 timotimo probably
20:17 brrt no, that's not true, we may be multiple inlines deep
20:17 timotimo first step: bail out of bridge building if we're in inlines at all ;)
20:18 brrt you can also add a new inline to the table for +the bridged part
20:18 brrt argh, rats on the keyboard
20:19 timotimo :)
20:19 jnthn timotimo: No no, the releaes process :P
20:22 PerlJam .oO( Due to a freak laundry accident, MoarVM is unable to be released )
20:24 timotimo oi don't jinx it!
20:25 brrt hmm
20:25 PerlJam timotimo: jnthn can already circumvent any jinx by increasing the bus number   :)
20:26 timotimo you may be able to increase the bus number, but the jnthn amount seems to be ceiling'd at 1 :(
20:26 PerlJam (Where does this weird idea that speaking of thing makes it happen come from?)
20:26 brrt i suppose that if we *are* multiple inlines deep, their nesting structure can still be determined, but i'm not sure how that would happen without spesh coegen
20:26 brrt PerlJam: magic thinking, one of the most ancient human biiases
20:27 brrt unless we encode the nesting structure in some other way
20:29 PerlJam brrt: I suppose at some point in the past someone said something like "I hope it rains today" and then it did.  Thus confirming that speaking of a thing makes it happen.  :)
20:29 timotimo i'm pretty sure handlers always bound things within the linear order
20:30 brrt i think it can be generalised to the overactive agent detection bias
20:31 brrt handlers? no, i'm talking about inline boundaries
20:32 brrt these are generated at spesh-codegen-time
20:32 timotimo right, but wouldn't they work similar to that? regarding linear_next and all?
20:32 timotimo i'm pretty sure inlines just get pasted at the end of an existing spesh graph, so they'd always end up a linear blob from begin of inline to end
20:33 brrt yes
20:33 timotimo following that logic, the inner inlines would be at the end of an existing inline
20:33 timotimo seems somewhat easy
20:33 brrt that is not the problem
20:35 timotimo oh
20:35 timotimo i seem to not be experienced enough with the inline stuff to get this
20:36 timotimo to be fair, the thought of inline deopt has scared me a little bit ... chopping up the current frame into multiple pieces and turning them into multiple proper frames again ... :)
20:37 jnthn Inline deopt is...a bit intricate
20:37 jnthn I need to sleep now, so don't have time to get the full context of what's being discussed
20:37 timotimo good night and get well soon!
20:37 jnthn But one note: the inlines offset table is ordered
20:37 timotimo also, good flight!
20:38 jnthn Quite carefully iirc
20:38 jnthn So you will always encounter them going "outwards", or "towards callers" if you walk the table in order.
20:38 jnthn And the deopt logic relies on that.
20:39 jnthn It's the same trick with the handlers table too: a linear scan gets you the innermost applicable one
20:40 brrt right. but what i'm saying is, that relies on having the spesh-codegen-created offset, and i'd like to get rid of that, as it isn't very cheap to maintain for the JIT
20:40 jnthn brrt: But you have the inline index, no?
20:40 brrt oh well, sleep well anyway :-)
20:40 jnthn (at JIT time, I mean)
20:40 brrt yes
20:41 brrt i do, even if we'd never codegen
20:41 jnthn Maybe that helps :)
20:41 jnthn Anyway, sleep time... :) o/
20:41 brrt sleep well
20:41 timotimo so just copying out the table after spesh is done isn't an option
20:41 jnthn Thanks! 'night
20:41 timotimo but we do want the spesh phase
20:41 timotimo so the part that we'd throw out is the part that turns the spesh graph back into a linear slice of code
20:41 timotimo hmm.
20:42 timotimo would it be enough for a "replacement" just to have a linear scan through the spesh graph and note the sizes of the used instructions?
20:42 brrt yes. spesh stays, but creating an optimized bytecode frame goes
20:42 brrt hmmm
20:42 brrt that would work, yes
20:43 brrt hacky, but ok
20:43 timotimo have you had a better idea yet?
20:44 brrt well, pass the inline index directly to the deopt_one function, would be my idea
20:44 brrt and figure out how you'd need to uninline from there
20:44 timotimo oh, hm
20:46 brrt the inlines table is created during inlining, before codegen, so i'd think we'd be okay there
20:52 timotimo mh
20:53 brrt yes, complex stuff, i know
20:57 timotimo it doesn't seem terribly complex yet
20:57 timotimo putting the deopt target directly into the code seems like another kind of devirtualization
20:57 timotimo there was a frame that used to deopt on 99% of calls to it
20:57 brrt hmm yes
20:57 timotimo right before the very end of the code, but still
20:57 brrt really? :-o
20:57 timotimo yeah
20:57 brrt we did something wrong there, clearly
20:58 timotimo it was caused by a "try" where putting a $! = Any in front removed the deopts
20:58 timotimo but i couldn't measure a difference in performance
20:58 brrt still
20:58 timotimo yeah, we logged a type or something for the contents of $! and that "suddenly" turned out not to be true any more
20:59 timotimo however, we assigned to $! next, so i don't really know what would have caused the guard to become used
20:59 brrt if you don't care about wastefulnes emotionally, how will you ever achieve greatness
21:00 timotimo "wer den pfennig nicht ehrt ist des talers nicht wert"
21:01 brrt we have that in dutch too
21:02 timotimo i think i know that originally from scrooge mcduck
21:03 brrt nice :-)
21:04 brrt dutch people are miserly enough to use it all the time
21:04 brrt in money terms, its probably not correct though
22:06 vendethiel joined #moarvm
22:34 tadzik joined #moarvm
23:25 xiaomiao joined #moarvm
23:47 jepeway joined #moarvm

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