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