Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2016-03-28

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

All times shown according to UTC.

Time Nick Message
00:07 dalek MoarVM: e688260 | timotimo++ | src/6model/reprs/MVMStaticFrame.c:
00:07 dalek MoarVM: add instrumentation values to MVMStaticFrame's unmanaged size.
00:07 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/e688260d53
00:07 dalek MoarVM: 4812655 | timotimo++ | src/6model/reprs/MVMStaticFrame.c:
00:07 dalek MoarVM: account for unmanaged_size of spesh candidates and jitcode.
00:07 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/481265520b
00:07 timotimo so much typing
00:07 timotimo but at least don't requires the brane
00:17 travis-ci joined #moarvm
00:17 travis-ci MoarVM build failed. Timo Paulssen 'account for unmanaged_size of spesh candidates and jitcode.'
00:17 travis-ci https://travis-ci.org/MoarVM/MoarVM/builds/118890447 https://github.com/MoarVM/MoarVM/compare/543c727270c0...481265520bd8
00:17 travis-ci left #moarvm
00:19 timotimo oh well
00:20 vendethiel joined #moarvm
00:20 dalek MoarVM: 2e303cf | timotimo++ | src/6model/reprs/MVMStaticFrame.c:
00:20 dalek MoarVM: fix the typos
00:20 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/2e303cf175
00:32 travis-ci joined #moarvm
00:32 travis-ci MoarVM build passed. Timo Paulssen 'fix the typos'
00:32 travis-ci https://travis-ci.org/MoarVM/MoarVM/builds/118891517 https://github.com/MoarVM/MoarVM/compare/481265520bd8...2e303cf17554
00:32 travis-ci left #moarvm
00:46 timotimo i feel like merging the annotate_refs_reprapi branch into maste
00:46 timotimo master
00:53 timotimo sometimes the ABC object is kept alive by a method cache of some random object %)
00:55 timotimo quite likely somewhere in the compiler, i'd suggest
00:55 timotimo but QAST::Var (STable) (44777)
00:55 timotimo --[ Method cache ]-->
00:55 timotimo isn't so terribly insightful, i dare say
01:02 timotimo good news! when i run the eval 30 times, i only find like 27 ABCs!
01:03 timotimo so at some point it'll probably just stop leaking :D
01:04 timotimo because at some point all caches and such will be filled and nothing more will get in :D
01:10 timotimo out of 90 goes through the for loop for evaling, 74 ABC stables stay around :\
01:13 timotimo 571 megabytes of heap dump data ... no big deal :P
01:14 vendethiel joined #moarvm
01:20 timotimo OK, with 200 runs through the eval, only 108 STables with type="ABC" stick around
01:42 timotimo http://t.h8.lv/all_paths_here.png  ;  with the patch i have, it doesn't seem like the int cache is eliminated "enough"
01:46 timotimo jnthn: you may find this interesting; i'm not going to throw away the raw data, i'll also upload the .dot file
01:46 timotimo http://t.h8.lv/all_paths_here.dot
01:46 timotimo http://t.h8.lv/all_paths.txt - this is the raw output from our heap analyzer, btw, it has the edge infos, too.
01:48 ilbot3 joined #moarvm
01:48 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
01:49 timotimo er, not 74
05:52 TimToady joined #moarvm
06:48 domidumont joined #moarvm
06:53 domidumont joined #moarvm
07:48 * timotimo also includes the actual root that caused something to be included
07:49 timotimo and next step would be to also include the descriptions of the paths, but that could bloat up the image quite a bit. i have an idea for that, though. almost a clever one :)
08:12 sivoais joined #moarvm
08:15 timotimo the files are already updated at their original URL, yay
08:16 timotimo and the script i've been making for this is in my fork of the heapanalyzer
10:58 FROGGS joined #moarvm
11:17 vendethiel joined #moarvm
11:54 timotimo burgh. i'm trying to work on cross-inline optimizations and my changes actually cause an inline that used to succeed to fail now >:(
11:55 vendethiel joined #moarvm
12:02 timotimo in another place it causes a fastinvoke to turn into an invoke
12:02 timotimo i don't even :|
12:11 stmuk_ joined #moarvm
12:27 diakopter lolz
13:07 stmuk_ https://github.com/MoarVM/MoarVM/pull/350
13:07 Ven joined #moarvm
13:08 jnthn Can merge after travis :)
13:09 jnthn I'm a tad curious what $OS_FREEBSD{cc} is
13:09 jnthn And if that's a hardcoded value
13:11 stmuk_ its the result of     cc => (qx!cc -v 2>&1 >$devnull! !~ 'clang') ? 'gcc' : 'clang',$
13:12 stmuk_ probably the data structure should define cc in one place only
13:12 timotimo perhaps we should instead have two entries for freebsd; one with gcc and one with clang?
13:12 timotimo the interpolated value there sticks out like a sore thumb :)
13:13 stmuk_ well really I think all systems should detect gcc or clang rather than hardcode
13:13 stmuk_ I'd also assume quite a few people use gcc on solaris as well
13:13 timotimo mhm mhm
13:14 jnthn stmuk_: Fair enough, thanks
13:19 dalek MoarVM: eba9b0f | (Steve Mynott)++ | build/setup.pm:
13:19 dalek MoarVM: fix compile on FreeBSD 9
13:19 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/eba9b0f00c
13:19 dalek MoarVM: bccdea1 | jnthn++ | build/setup.pm:
13:19 dalek MoarVM: Merge pull request #350 from stmuk/master
13:19 dalek MoarVM:
13:19 dalek MoarVM: fix compile on FreeBSD 8 and 9 (also tested not to break 10)
13:19 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/bccdea1d1e
13:21 timotimo jnthn: +1/-1 on merging the "explain references" branch?
13:21 jnthn timotimo: Need to review it yet
13:23 timotimo gotcha
13:26 jnthn (Will be about top of my todo list when I have tuits though, because I want to use the functionality it adds :))
13:42 zakharyas joined #moarvm
14:04 diakopter yo yo
14:04 timotimo yo diakopter
14:04 timotimo how do yo do?
14:04 timotimo how yo yo yo?
14:04 diakopter more info on my config problem
14:04 timotimo yow yo yo yo?
14:04 diakopter add_entry(tc, config, "libdir", "C:\\Users\\mwilson\\src\\v\rakudo\\install\\bin");
14:04 diakopter from config.c
14:05 diakopter see any problem? :lolcry:
14:05 timotimo \r, yeah
14:06 diakopter I haven't exhaustively looked, but I hadn't found its origin yet
14:06 diakopter I was hoping someone else would know more offhand
14:07 timotimo no clue; all i know is something in Configure.pl must generate that file
14:07 timotimo which i bet you already knew
14:07 diakopter well I traced it back to moar's config
14:07 diakopter so it's not in rakudo/nqp
14:08 timotimo rakudon't
14:21 diakopter jnthn: any ideas?
14:34 jnthn diakopter: Not really...I'd look at the code that fills out config.c.in
14:34 jnthn grep for that I guess
14:35 diakopter oki
14:38 diakopter well, this is part of the cause, here's what nqp sent moar config:
14:39 diakopter CONFIG    = --optimize --prefix=C:\Users\mwilson\src\v/rakudo\install --make-install
14:40 diakopter (obviously it should handle that correctly too, though)
15:09 timotimo i wonder what other cases we have where we hold on to lots and lots and lots of stuff that we don't need any more at all
15:10 timotimo granted, the SC case is a bit more extreme than others would be
15:10 timotimo but we'll be running around with fully populated method caches and specialization for the whole compiler after going into the user code, for example
15:11 jnthn SCs are used to resolve all wval instructions, of which there are plenty
15:11 timotimo but i suppose the only part where that's really bothersome so far is those top 2 methods of the mast compiler?
15:13 jnthn As for the compiler...true, but you might EVAL, interpolate regex, etc.
15:13 timotimo ah, regex interpolation is a case i hadn't considered
15:40 Ven joined #moarvm
15:55 cognominal joined #moarvm
16:07 timotimo i just ran perf record on the heapanalyzer (up until i got a snapshot's summary)
16:07 timotimo looks like it spends a significant amount of time in the fixedsizealloc
16:07 timotimo by which i mean like 30%
16:08 * timotimo tries without jit to get more info, hopefully
16:11 jnthn Most multi-threaded things bottleneck on FSA at the moment...
16:12 jnthn (For frame allocations)
16:22 timotimo oh, OK
16:37 timotimo parse-static-frames gets quite a few things inlined, but it doesn't seem like the .Int method calls get fully inlined. instead, they turn into a thing that takes the dispatcher and invokes something that gets taken from a spesh slot
16:37 timotimo and those still contain hllize calls for some reason
16:38 timotimo ah, probably just the missing discovery step after inlining, so the known type doesn't make it
16:38 timotimo and thus no hll_owner
17:47 timotimo i hate it when spesh logs sufficiently diverge to not become easily diffable >_>
18:03 timotimo ah, one of the two pieces of output has disappeared
18:06 timotimo you poke spesh and *something* happens. but what? nobody knows
18:09 Ven joined #moarvm
19:17 timotimo i think i'll probably be stitching the inlined blocks into the dominance tree. because otherwise the spesh won't touch these newly added blocks
19:17 timotimo since it only goes by children, not by linear_next

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