00:35 colomon joined 01:12 FROGGS_ joined 05:13 colomon joined 05:39 Ven joined 06:34 brrt joined
brrt \o 06:34
nwc10 o/ 06:35
brrt you're up early :-)
nwc10 more than that, I'm in the office early
I blame the young man
who wasn't up *terribly* early. Just wasn't going back to sleep either. 06:36
And I figured that I wasn't either
brrt :-) 06:37
$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:55
nwc10 many a true word spoken in jest 06:56
my girlfriend's phone is still on 2.blah
and to the best of my knowledge there's never been an upgrade offered
brrt my phone - that i'm forced to use by my provider - is 2.2
and i'm quite happy nevertheless
07:04 zakharyas joined
sergot hi o/ 07:15
brrt hi sergot
sergot o/ brrt 07:18
07:29 FROGGS_ joined 08:37 zakharyas joined
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:30
brrt but.... trees! 09:32
basically, compared to the information you have at the compiler, doing it at bytecode level will resort to heuristics 09:33
i think
timotimo aha?
brrt pessimistic heuristics, so the analysis will be correct?
hmm
i'm thinking about this right now
timotimo you mean QAST or MAST?
brrt either
anyway, i'll be the first to admit that i haven't thought about this in great detail 09:34
timotimo mhm
brrt maybe the ssa forms makes i t really easy
i dunno
:-)
oh, there was another thing
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)
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
stack space = register space in moarvm of course 09:36
but maybe we could do something similar and depessimize register allocation
timotimo huh
not so sure about that
i mean: i don't think i properly understand
brrt i suppose in general you can't do that because of continuations
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?
brrt no.. that's not what i mean i think :-)
timotimo ok
brrt (communicating ideas one hardly understands is.. hard)
timotimo :)
brrt ok, but the point is this: a procedure calls another 09:38
the VM makes an activation record - basically, in java, stack space, in moar, an MVMFrame with associated work registers
and transfers control
timotimo right
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
i.e. for making it's own activation record
timotimo sounds kind of like bouncing control back and forth and back for procedure calls
brrt no, that's not what i mean 09:40
what i mean is that the sequence of control is this:
bytecode -> vm (makes activation record) -> bytecode
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
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?
hmm
brrt that means that a c-like routine can use effectively stack allocation for it's registers
in principle, that would hold for every 'regular' block-scoped thingy 09:43
timotimo can you implement a proof-of-concept?
we do a whole lot of inlining for block-scoped things already, don't we?
brrt no, because, this will conflict with (unlimited) continuations
yes
and obviously that's equivalent
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
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
brrt hmm yes
and even then you have mitigation strategies 09:47
as in, non-costly recoveries
timotimo mhh
like, a memcpy? :)
brrt no
basically, you have a stack with a layout like this
foo -> bar -> baz -> quix (takeclosure)
normally, when takeclosure is /not/ called, the return from baz to bar is a pointer decrement (increment in x86_64) 09:48
so the baz -> bar return is just a return
if quix is called, at that point the stack is still present
what you'd have to do is 'freeze' the stack at that point for quix 09:49
and simply not kill the stack when you return from quix to baz and further up
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
brrt you'd have (foo -> bar -> baz -> quix) (in continuation) followed by quam -> very -> foo
or perhaps allocated on a new block, i don't really care either way 09:51
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
... i guess my point is this (in general)
timotimo i still feel a bit tired, i'm not sure if i understand it enough to judge
brrt we currently use a (pessimistic) refcounting scheme for all frames
managed by the vm 09:53
however, we could in principle move to an optimistic stack allocation scheme for most frames, managed by the frames themselves
timotimo how does our frame cache factor into this?
brrt the frame cache is an optimization for the refcounting
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
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
lexicals are another matter altogether, though
the idea is similar to the whole iter optimization (dunno if that helped at all, though :-)) 09:57
timotimo mhm 10:00
i don't know what you mean with "the whole iter optimization" :(
lizmat GLR ? 10:04
timotimo i thought brrt may be refering to something much more low-level? 10:06
brrt no i mean the thingy were we optimized istrue(iter) to istrue_iterhash, istrue_iterarray, etc 10:08
and then made these cheap
(i.e. nonpolymorphic)
timotimo ah! 10:13
i sincerely do hope this optimization made stuff cheaper
brrt yes 10:20
i'd add that the next thing that is done with the iter is typically shift 10:21
and that we could usually easily do this too
i.e. depolymorphise
timotimo oh
that's not such a bad idea
brrt i hope :-) 10:22
i don't have time / computer availability to do it this weekend
at earliest i'd have to do it next weekend, but that's questionable too
timotimo i'll have a look at it either today or on the weekend. thanks for the tip! 10:24
also, i'd like to improve spesh_diff.p6
i think it doesn't handle the newest data format yet
and i'd like to give BBs a unique identifier across specialization, so that i can do a better job at diffing them 10:25
brrt yesh 10:26
good luck :-)
brrt afk
timotimo i think i'll just use their memory address
thanks
12:02 leont joined
jnthn Much wow. I managed to find a place to buy Delirium tremens. In China! 12:40
cognome is there pink elephants there too? 12:42
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:43
cognome: Didn't see any yet...except on the bottle, of course ;) 12:45
cognome jnthn, hopefully you don't drive : www.youtube.com/watch?v=ZwJfXgTO7J4 12:50
timotimo thanks for the clarification, jnthn 13:20
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:21
Or some limited form of it, depending on VM interface. 13:22
13:53 leedo joined 14:23 ilbot3 joined, Util joined 14:25 [Coke] joined, masak joined 14:44 d4l3k_ joined 14:48 flussence joined 15:02 tadzik joined, jlaire_ joined 15:04 perlpilot joined, camelia joined 15:08 FROGGS[mobile] joined 15:31 retupmoc1 joined, cxreg2 joined, avar joined, danaj_ joined 15:46 avar joined 15:54 leont joined 15:57 FROGGS[mobile] joined 16:01 FROGGS joined 17:30 zakharyas joined
dalek arVM: 8962053 | (Tobias Leich)++ | src/io/io.c:
improve err msg about oob in io_read_bytes
 17:36
18:05 cognome joined
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
I was thinking of looking at rt.perl.org/Ticket/Display.html?id=122773
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
hoelzro tries 18:55
FROGGS and a grep for merge_globals or merge on its own
hoelzro spesh disabling doesn't affect it 18:56
nothing in the rakudo module debug output seems odd 18:57
FROGGS hoelzro: you maybe want to dump the symbols that get merged in ModuleLoader 19:02
hoelzro FROGGS: good idea 19:04
I can try that next
FROGGS and now imagine to debug that on parrot :P
2014 has been good for us 19:05
hoelzro FROGGS: thankfully, this problem isn't happening on Parrot =)
just Moar/JVM
but it's keeping me from working on stuff I want to do 19:06
20:48 cognome joined 21:45 cognome joined 21:47 cognome joined 22:05 leont 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!