00:30 Ven joined 02:11 lizmat_ joined 02:25 mojca joined 04:53 vendethiel joined 06:36 domidumont joined 06:38 domidumont joined 06:49 mojca joined 07:06 domidumont joined 07:11 FROGGS joined 07:12 domidumont joined 08:05 zakharyas joined 08:17 Ven joined 08:44 mojca joined 09:00 zakharyas1 joined 09:19 vendethiel joined 11:21 vendethiel joined 11:36 brrt joined
brrt good * #moarvm 11:43
jnthn o/ brrt
brrt \o jnthn
nice writeup on the heap profiler :-)
ooc, what do you think would be a decent benchmark to test the effect of -fno-omit-frame-pointer 11:46
basically, if -fno-omit-frame-pointer is cheap, then we can start looking at entirely new strategies in both the JIT and the GC 11:47
GC can use a conservative stack-walking collector, which means no more temp roots 11:48
timotimo does anybody have a clue if it might be worth it checking the current stack of frames to see if an upper frame already has a reference on a frame we'd invoke? so that we can save a inc/dec cycle, which would cause a memory fence
brrt probably not
but, that is just a feeling 11:49
:-)
basically, you're going to do an O(N) algorithm to save on a O(1) operation, and that is disregarding the cost of cache misses
and, i recall reading that in case of no actual contention, atomic updates ought to be cheap 11:50
but, i don't know where
timotimo if you have a simple "run this code in multiple threads" parallelization, you'll end up invoking the same frames all the time on all your threads 11:51
so the contention is actually real, at least if your individual functions end up being small 11:52
brrt hmm... really? staticframes, but not frames, i'd think?
timotimo every time we invoke a staticframe, we inc its ref, don't we?
brrt .. i did not know that
timotimo that's why i always see incref and decref and such in the perf output 11:53
and why i implemented at least two of those incs and decs without atomic ops when moar says there are no user threads
jnthn brrt: Uh, we can't do conservative
brrt: 'cus we move 11:54
brrt oh, right
good point
jnthn timotimo: refs are on frames, not static frames
ref counts, that is
timotimo oh, oops 11:55
jnthn static frames are just normal collectable objects
timotimo does that invalidate the idea i had?
jnthn We can do better on frames, but...it'll need more than just some tweakery :)
brrt i'm very curious about the list of reasons for refcounted frames actually :-)
well, it should invalidate the idea of contention on frames 11:56
jnthn brrt: Well, thanks to closures you don't really have a simple stack any more
But more a frame tree
So you have to manage that memory somehow
brrt why we can't have nice things
jnthn And if you do it by having the GC manage them then a bunch of code that never allocates (e.g. is doing lots of work with native types), but does invoke, would cause GC anyway. 11:57
brrt hmm
jnthn What I've been pondering (but I need to do a lot more thinking/design work on it) is to have a simple stack anyway, until a point we realize "oops, we can't"
brrt what if we could prove that a certain set of frames behaved stackish
jnthn And then we will actually promote them to full GC-able objects. 11:58
brrt hmmm
that seems doable
optimistically speaking
jnthn Which in turn would get rid of the GC performance issues around closures (which arises from the reference counting scheme not playing nice with generational GC)
brrt or better said
when will it not be feasible 11:59
jnthn Well, the hard part is working out a design that isn't complex
And so we won't end up with it screwing up
:)
It's basically a kind of "escape" problem
brrt i can think of two non-stackish things: closures and continuations
jnthn Right
And closures are endemic 12:00
timotimo yeah, they're all around
brrt yes, but, both are explicit in the bytecode
jnthn True
brrt so from our level, we know when they happen
what would be interesting is if we could prove that a given closure never referenced upward beyond a certain frame 12:01
jnthn Anyway, I've been pondering things in that area, 'cus I really want to get the cost of invocation down.
brrt in general that means no dynamic lexicals
e.g. A -> B -> C -> D, if we'd take a closure on D, that closure would not 'reach' beyond C, then we could heap-promote the block from C -> D, but leave A->B as a stack 12:02
jnthn I suspect we'll need to uphold an invariant along the lines of stack can reference GC-ables, gut GC-ables can't reference stack
*but
brrt oh, right
jnthn That *may* be sufficient in fact.
brrt let me think about that
jnthn However, a frame becoming GCable rather than stack then implies contaigion 12:03
brrt GC-ables would include closures in this scheme, right?
jnthn Absolutely.
What *is* interesting though, is to realize that escape analysis and its applications basically turn GC-able to stack
brrt uhuh 12:04
timotimo right; but we're kind-of far off from full escape analysis, aren't we?
brrt i suppose stack objects would be marked with an appropriate flag?
jnthn So if we were to leave it to plain old escape analysis to prove closures don't escape, we might be able to just implement the really simple invariant and not be any more clever than that.
brrt: Something like, I guess. :)
brrt i've grown fond of not being clever 12:05
jnthn Yes, anyone can come up with a clever design...
But they tend to be fragile
timotimo: Well, yes and no. It's not risen to the top of the priority list yet. 12:06
timotimo: But MoarVM was generally deprioritized by me a bit last year, to focus on Perl 6 language issues.
timotimo has the approach you sketched out with masak bitrotted?
aye
jnthn But by now we've shipped 6.c, and I don't have to worry about Perl 6 from a lang design point of view for now.
brrt we're basically in need of a giant surplus of energy on MoarVM
jnthn So I can go back to focusing on compiler/VM things :) 12:07
Anyway, lunch time :) bbs :) 12:08
brrt lunch well :-)
12:20 vendethiel joined 12:50 vendethiel joined 13:18 dlem joined
dlem .tell jnthn Regarding your discussion with brrt above, I coincidentally came across an article today which may or may not be of interest to you: blog.rocana.com/golang-escape-analysis 13:20
dlem apologizes for lurking by way of irclog.perlgeek.de/moarvm :-) 13:21
brrt no apology necessary 13:23
dlem .tell jnthn Oh, and the article has a link to an Escape Analysis paper for Java. You may already have read it :-)
brrt: Phew :-)
jnthn dlem: Thanks for the link. I was lucky enough to run into a couple of Go compiler folks last summer and they they mentioned escape analysis, and that it'd cut a good bit of GC work out. :) 13:25
So will be interseting to read
dlem jnthn: OK! Outstanding work on MoarVM / Rakudo - a real thriller to watch the development :-) 13:27
dlem goes back to $work 13:29
13:38 vendethiel joined 14:03 Ven joined 15:50 vendethiel joined
dalek arVM/heap-profiler: f12e77b | jnthn++ | src/gc/roots.c:
Split out register and lexical marking.

We'll re-use the registers part from the heap snapshot analyzer, but not the lexicals bit since those have names and we'd like to include those.		 16:34
arVM/heap-profiler: 48ca567 | jnthn++ | src/ (4 files):
Include all frame references into heap snapshot.
arVM/heap-profiler: 41403d2 | jnthn++ | src/profiler/heapsnapshot.h:
Be consistent with sized types.
 16:49
arVM/heap-profiler: af6791b | jnthn++ | src/profiler/heapsnapshot.c:
Include static frames data in output.
arVM/heap-profiler: 8cb0fba | jnthn++ | src/profiler/heapsnapshot.c:
Fix size thinko, correcting junk output.
 17:11
jnthn OK, now the heap snapshot for Rakudo looks sorta sensible 17:12
And 21MB. Just at startup 17:13
17:48 geekosaur joined
dalek Heuristic branch merge: pushed 46 commits to MoarVM by jnthn 17:53
jnthn Merged the heap profiler :)
nwc10 oh, I just did that locally and ASAN still tolerates you 17:54
jnthn :)
18:26 mojca joined 18:28 domidumont joined 19:03 vendethiel joined 19:17 mojca joined 19:22 FROGGS joined 19:47 vendethiel joined 20:12 synopsebot6 joined 22:56 mojca joined 23:32 vendethiel 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!