Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2014-09-19

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

All times shown according to UTC.

Time Nick Message
00:35 colomon joined #moarvm
01:12 FROGGS_ joined #moarvm
05:13 colomon joined #moarvm
05:39 Ven joined #moarvm
06:34 brrt joined #moarvm
06:34 brrt \o
06:35 nwc10 o/
06:35 brrt you're up early :-)
06:35 nwc10 more than that, I'm in the office early
06:35 nwc10 I blame the young man
06:36 nwc10 who wasn't up *terribly* early. Just wasn't going back to sleep either.
06:36 nwc10 And I figured that I wasn't either
06:37 brrt :-)
06:55 brrt $dayjob company is in great amount of stress because their apps broke for the iOS8 release. i made a joke that if it had been android nobody would've been bothered for months. they didn't like it
06:56 nwc10 many a true word spoken in jest
06:56 nwc10 my girlfriend's phone is still on 2.blah
06:56 nwc10 and to the best of my knowledge there's never been an upgrade offered
06:56 brrt my phone - that i'm forced to use by my provider - is 2.2
06:56 brrt and i'm quite happy nevertheless
07:04 zakharyas joined #moarvm
07:15 sergot hi o/
07:15 brrt hi sergot
07:18 sergot o/ brrt
07:29 FROGGS_ joined #moarvm
08:37 zakharyas joined #moarvm
09:30 timotimo brrt: another thing i just noticed: doing escape analysis on the bytecode level is better as a lot more inlining has happened at that point
09:32 brrt but.... trees!
09:33 brrt basically, compared to the information you have at the compiler, doing it at bytecode level will resort to heuristics
09:33 brrt i think
09:33 timotimo aha?
09:33 brrt pessimistic heuristics, so the analysis will be correct?
09:33 brrt hmm
09:33 brrt i'm thinking about this right now
09:33 timotimo you mean QAST or MAST?
09:33 brrt either
09:34 brrt anyway, i'll be the first to admit that i haven't thought about this in great detail
09:34 timotimo mhm
09:34 brrt maybe the ssa forms makes i t really easy
09:34 brrt i dunno
09:34 brrt :-)
09:34 brrt oh, there was another thing
09:35 timotimo another thing: if you have escape analysis data on the tree, how do you properly transfer it through to the bytecode stage?
09:35 brrt i was thinking about how java implements anonymous inner classes (as closures, with the whole 'final' thing)
09:35 brrt and it occured to me that they could have solved quite a few problems for themselves if the routines were responsible for their own allocation of stack space
09:36 brrt stack space = register space in moarvm of course
09:36 brrt but maybe we could do something similar and depessimize register allocation
09:36 timotimo huh
09:36 timotimo not so sure about that
09:36 timotimo i mean: i don't think i properly understand
09:36 brrt i suppose in general you can't do that because of continuations
09:37 brrt alright, think about how java implements a procedure call
09:37 timotimo and you could pass on the type object and do mixins and stuff; would that be happy on register space?
09:37 brrt no.. that's not what i mean i think :-)
09:37 timotimo ok
09:37 brrt (communicating ideas one hardly understands is.. hard)
09:37 timotimo :)
09:38 brrt ok, but the point is this: a procedure calls another
09:38 brrt the VM makes an activation record - basically, in java, stack space, in moar, an MVMFrame with associated work registers
09:38 brrt and transfers control
09:38 timotimo right
09:39 brrt what if - instead the VM doing this the same way for every procedure call, the procedure was responsible for allocating it's own batch of register space
09:39 brrt i.e. for making it's own activation record
09:39 timotimo sounds kind of like bouncing control back and forth and back for procedure calls
09:40 brrt no, that's not what i mean
09:40 brrt what i mean is that the sequence of control is this:
09:40 brrt bytecode -> vm (makes activation record) -> bytecode
09:41 brrt what i think would be possible is bytecode -> vm (makes very minimal activation record) -> bytecode (makes rest of activation record)
09:41 timotimo hmm, dunno
09:42 brrt that way, you'll only have to heap-allocate the register space *if* you're going to make a closure, and never otherwise
09:42 timotimo what does that improve?
09:42 timotimo hmm
09:42 brrt that means that a c-like routine can use effectively stack allocation for it's registers
09:43 brrt in principle, that would hold for every 'regular' block-scoped thingy
09:43 timotimo can you implement a proof-of-concept?
09:43 timotimo we do a whole lot of inlining for block-scoped things already, don't we?
09:43 brrt no, because, this will conflict with (unlimited) continuations
09:43 brrt yes
09:43 brrt and obviously that's equivalent
09:44 brrt because if i do this, and i make an unlimited continuation, and at some p oint it is invoked.... well, all my stack will be gone
09:44 timotimo mhm
09:45 brrt which is why unlimited continuations suck
09:45 timotimo so you'd need to know in front if there'll be a takecontinuation or costily deopt if it shows up
09:45 brrt hmm yes
09:47 brrt and even then you have mitigation strategies
09:47 brrt as in, non-costly recoveries
09:47 timotimo mhh
09:47 timotimo like, a memcpy? :)
09:47 brrt no
09:47 brrt basically, you have a stack with a layout like this
09:47 brrt foo -> bar -> baz -> quix (takeclosure)
09:48 brrt normally, when takeclosure is /not/ called, the return from baz to bar is a pointer decrement (increment in x86_64)
09:48 brrt so the baz -> bar return is just a return
09:48 brrt if quix is called, at that point the stack is still present
09:49 brrt what you'd have to do is 'freeze' the stack at that point for quix
09:49 brrt and simply not kill the stack when you return from quix to baz and further up
09:50 brrt so that if baz calls quam after quix, it would be allocated somewhere else
09:50 timotimo that sounds a bit like the stackless transformation of pypy
09:50 brrt you'd have (foo -> bar -> baz -> quix) (in continuation) followed by quam -> very -> foo
09:51 brrt or perhaps allocated on a new block, i don't really care either way
09:52 brrt but all you need to do - in principle - is set a flag somewhere that your stack is frozen and have the return behaviour take this into account
09:52 brrt ... i guess my point is this (in general)
09:52 timotimo i still feel a bit tired, i'm not sure if i understand it enough to judge
09:52 brrt we currently use a (pessimistic) refcounting scheme for all frames
09:53 brrt managed by the vm
09:53 brrt however, we could in principle move to an optimistic stack allocation scheme for most frames, managed by the frames themselves
09:53 timotimo how does our frame cache factor into this?
09:53 brrt the frame cache is an optimization for the refcounting
09:54 timotimo mhm
09:54 brrt so you could still do that, however the plan would be that most frames are allocated in a single stack block
09:55 brrt and tbh.. the more we take out of the mvmframe, and the simpler we make the management of it, and also the more explicit, the easier it will be for the JIT to optimize it
09:55 brrt lexicals are another matter altogether, though
09:57 brrt the idea is similar to the whole iter optimization (dunno if that helped at all, though :-))
10:00 timotimo mhm
10:00 timotimo i don't know what you mean with "the whole iter optimization" :(
10:04 lizmat GLR ?
10:06 timotimo i thought brrt may be refering to something much more low-level?
10:08 brrt no i mean the thingy were we optimized istrue(iter) to istrue_iterhash, istrue_iterarray, etc
10:08 brrt and then made these cheap
10:08 brrt (i.e. nonpolymorphic)
10:13 timotimo ah!
10:13 timotimo i sincerely do hope this optimization made stuff cheaper
10:20 brrt yes
10:21 brrt i'd add that the next thing that is done with the iter is typically shift
10:21 brrt and that we could usually easily do this too
10:21 brrt i.e. depolymorphise
10:21 timotimo oh
10:21 timotimo that's not such a bad idea
10:22 brrt i hope :-)
10:22 brrt i don't have time / computer availability to do it this weekend
10:22 brrt at earliest i'd have to do it next weekend, but that's questionable too
10:24 timotimo i'll have a look at it either today or on the weekend. thanks for the tip!
10:24 timotimo also, i'd like to improve spesh_diff.p6
10:24 timotimo i think it doesn't handle the newest data format yet
10:25 timotimo and i'd like to give BBs a unique identifier across specialization, so that i can do a better job at diffing them
10:26 brrt yesh
10:26 brrt good luck  :-)
10:26 * brrt afk
10:26 timotimo i think i'll just use their memory address
10:26 timotimo thanks
12:02 leont joined #moarvm
12:40 jnthn Much wow. I managed to find a place to buy Delirium tremens. In China!
12:42 cognome is there pink elephants there too?
12:43 jnthn SSA certainly helps a good bit with escape analysis. JVMs and, afaik, CLR does it at the bytecode level. And yes, inlining helps a lot.
12:45 jnthn cognome: Didn't see any yet...except on the bottle, of course ;)
12:50 cognome jnthn, hopefully you don't drive :  https://www.youtube.com/watch?v=ZwJfXgTO7J4
13:20 timotimo thanks for the clarification, jnthn
13:21 jnthn The trouble with doing stuff above bytecode level wrt allocation is that to be typesafe the VM would have to prove the thing won't live beyond the lifetime it's meant to...which basically means doing escape analysis.
13:22 jnthn Or some limited form of it, depending on VM interface.
13:53 leedo joined #moarvm
14:23 ilbot3 joined #moarvm
14:23 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
14:23 Util joined #moarvm
14:25 [Coke] joined #moarvm
14:25 masak joined #moarvm
14:44 d4l3k_ joined #moarvm
14:48 flussence joined #moarvm
15:02 tadzik joined #moarvm
15:02 jlaire_ joined #moarvm
15:04 perlpilot joined #moarvm
15:04 camelia joined #moarvm
15:08 FROGGS[mobile] joined #moarvm
15:31 retupmoc1 joined #moarvm
15:31 cxreg2 joined #moarvm
15:31 avar joined #moarvm
15:31 avar joined #moarvm
15:31 danaj_ joined #moarvm
15:46 avar joined #moarvm
15:46 avar joined #moarvm
15:54 leont joined #moarvm
15:57 FROGGS[mobile] joined #moarvm
16:01 FROGGS joined #moarvm
17:30 zakharyas joined #moarvm
17:36 dalek MoarVM: 8962053 | (Tobias Leich)++ | src/io/io.c:
17:36 dalek MoarVM: improve err msg about oob in io_read_bytes
17:36 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/8962053770
18:05 cognome joined #moarvm
18:53 hoelzro is there an env var or something one can flip on to get Moar to spit out a bunch of debugging info?
18:53 hoelzro I was thinking of looking at https://rt.perl.org/Ticket/Display.html?id=122773
18:54 timotimo there are MVM_SPESH_LOG=filename and MVM_JIT_LOG=filename, but those are unlikely to help unless turning off spesh or jit makes it work
18:54 FROGGS RAKUDO_MODULE_DEBUG=1 might be a start
18:55 * hoelzro tries
18:55 FROGGS and a grep for merge_globals or merge on its own
18:56 hoelzro spesh disabling doesn't affect it
18:57 hoelzro nothing in the rakudo module debug output seems odd
19:02 FROGGS hoelzro: you maybe want to dump the symbols that get merged in ModuleLoader
19:04 hoelzro FROGGS: good idea
19:04 hoelzro I can try that next
19:04 FROGGS and now imagine to debug that on parrot :P
19:05 FROGGS 2014 has been good for us
19:05 hoelzro FROGGS: thankfully, this problem isn't happening on Parrot =)
19:05 hoelzro just Moar/JVM
19:06 hoelzro but it's keeping me from working on stuff I want to do
20:48 cognome joined #moarvm
21:45 cognome joined #moarvm
21:47 cognome joined #moarvm
22:05 leont joined #moarvm

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