00:44 vendethiel joined 01:27 vendethiel joined 03:05 vendethiel joined 04:38 vendethiel joined 04:54 vendethiel joined 06:57 vendethiel joined 07:00 domidumont joined 07:05 domidumont joined 07:15 zakharyas joined 07:19 FROGGS[mobile]2 joined 07:25 vendethiel joined 07:40 flaviusb joined 07:53 vendethiel joined 07:56 FROGGS joined 08:10 Ven joined 08:19 zakharyas1 joined
timotimo i find in my thoughts about game development + perl6 that an op like force_gc that lets you specify a threshold for "if the nursery is at least this full, do the GC run" would be nice to have 08:40
so you could put it at the beginning of your main loop when basically every piece of "work" relating to a frame has been done and all temporary stuff has hopefully become garbage, and if you find a good ratio, you'll end up with nice short GC cycles (not too many roots, because the call stack is so flat, and the loop body has only just been re-entered) that may fit better into "wait for vsync" 08:42
(but at this point, really good framerates are hard to reach with complicated code anyway) 08:43
09:38 brrt joined
brrt \o 09:38
timotimo o/
brrt hmm, i figured out on the bus why the tiler-linearised compiler fails 09:39
basically, i don't deal with stuff like copy and 'immortals' anymore 09:40
(i'm thinking of calling them divine rather than immortal
09:40 leont joined
brrt because, omnipresent and never expiring 09:40
\o leont
timotimo oh
leont o/
timotimo a revelation!
brrt anyway, i should probably try what happens if i restore these, before i continue on with the offline register allocator 09:42
timotimo sure 09:43
brrt which, by the way, will deal with all that in quite a different maner 09:44
timotimo oh, hmm 09:45
brrt my next presentation will be thus: 'MoarVM JIT is open for hacking'
timotimo ooooooh
brrt which means i have to fix them issues first, of course
timotimo when is that going to happen? :) :)
brrt after my thesis is done, that's for sure 09:46
timotimo mhm
yeah, that makes sense, definitely
brrt but, i kind of designed the thing for hackability, right, so it would be wasteful if i didn't at least advertise it
timotimo sure :D 09:47
moritz brrt: coming to GPW2016? :-) 09:49
brrt no, not likely, that will be in march right?
*maybe* to NLPW
moritz yes, March 09:50
brrt hmmm.... 'fraid to say no :-( 09:51
timotimo gaaarrrgh, i still haven't done any preparation for GPW at all
no hotel booked, no entry fee paid, no talk topic come-up-withed
brrt still possible talk slots? 09:52
well, you could talk about the inner details of spesh if you wished :-)
i think you know a lot about that
moritz yes, there are still a few slots 09:53
(and we have the option to use two rooms on one or two days, so a bit of flexibility too) 09:54
brrt lots of things to do 09:55
hey, i might even have a somewhat better topic for you timotimo :-)
depends of course what you think of it yourself
you maintain the perl6 weekly, right? 09:56
timotimo oh?
uh
well ... i try
not too much success in the recent weeks, though
brrt well, that gives you a unique overview of activity in perl6-land
i think that could be a topic of interest
moritz or you could talk about the experience of running that blog, what kinds of feedback you get etc.
brrt lots of folks are talking about progress, stability, infrastructure 09:57
that, too
but by just running that blog, you can basically compare the state of affairs say, january 2015 with january 2016 :-)
anyway 09:58
just a suggestion, no pressure intended :-)
10:09 vendethiel joined 10:11 cognominal joined 10:37 vendethiel joined 11:10 domidumont joined 11:13 Ven joined 11:26 vendethiel joined 11:54 FROGGS joined 11:57 brrt joined 12:25 vendethiel joined 12:38 Ven joined 12:50 vendethiel joined 13:54 vendethiel joined 14:23 vendethiel joined 15:12 vendethiel joined 15:23 Ven joined 15:29 Ven joined 15:52 vendethiel joined 16:16 vendethiel joined 16:39 vendethiel joined 17:06 vendethiel joined 17:39 vendethiel joined
timotimo hmm 18:00
18:03 leont joined, vendethiel joined
timotimo a little "for $f.lines { $ccount += $_.chars; $lcount += 1; }" only inlines the .chars, not the addition operators ;( 18:08
(not natively typed $ccount and $lcount
18:08 domidumont joined
timotimo but if i typed them native int, they'd most probably completely prevent inlining because of the intlexref problem) 18:09
in the profile, infix:<+> only accounts for 3.35% of inclusive as well as exclusive time, but i expect the overhead of invoking it twice per loop is noticable 18:16
timotimo tries without adding stuff
yeah, with only = instead of += the exclusive time spent in that <anon> goes down to 2.91% from 20.5% 18:19
18:26 patrickz joined 18:34 FROGGS joined 18:53 vendethiel joined 19:22 vendethiel joined
timotimo actually, with native ints, the whole things takes slightly less time 19:32
but - as expected - it doesn't inline the + calls there either 19:37
and it runs 2x as many GCs as the one with "Int" rather than "int" 19:38
19:40 leont joined 20:01 donaldh joined
dalek arVM: a98eecc | jnthn++ | src/spesh/candidate.c:
Missing free of spesh graphs.

If we ended up destorying the spesh candidate before work on it completed, we'd leak the graph.		 21:32
arVM: b6c9af3 | jnthn++ | src/6model/reprs/SCRef.c:
Free SC root objects when freeing SC.
arVM: 7c9d32d | jnthn++ | src/core/threadcontext.c:
Free per-thread NFA evaluation memory.
 21:37
arVM: bffdbf3 | jnthn++ | src/core/threadcontext.c:
Free per-thread lexotic cache.
 21:41
arVM: f6e5da9 | jnthn++ | src/core/callsite.c:
Missing free of arg_names when interning.
 21:46
arVM: e6b527d | jnthn++ | src/6model/reprs/SCRef.c:
Free deserialization work index lists.
 21:52
jnthn With --full-cleanup, nqp -e "say(1)" now exits with less than 10KB lost (as opposed to around 350KB before those patches) 21:54
hoelzro jnthn++ 21:58
jnthn At the moment it's near impossible to distinguish real leaks from incomplete cleanups, and most of the above are leaks that could come up with EVAL or creating/tearing down lots of threads anyway. 22:00
22:05 vendethiel joined
jnthn Enough for today. 'night o/ 22:09
22:26 nebuchadnezzar joined
japhb jnthn++ # Plugging leaks, especially leaks that are worse under high concurrency/churn 23:17
23:17 vendethiel joined 23:47 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!