Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2016-02-08

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

All times shown according to UTC.

Time Nick Message
00:07 AmsterdamJoe joined #moarvm
00:07 vendethiel joined #moarvm
02:18 vendethiel joined #moarvm
02:47 ilbot3 joined #moarvm
02:47 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
02:59 FROGGS_ joined #moarvm
03:27 colomon joined #moarvm
04:39 vendethiel joined #moarvm
06:39 vendethiel joined #moarvm
07:11 FROGGS joined #moarvm
07:33 domidumont joined #moarvm
07:38 domidumont joined #moarvm
07:42 vendethiel joined #moarvm
09:34 kjs_ joined #moarvm
10:07 jnthn In prep for upcoming reliability and performance work, I'll be setting up various daily measurements. Will do a valgrind no-leak one once my work on that is a bit further along, and a spesh-immediately one too. For now, though, there's a daily run of perl6-bench on Rakudo head: http://www.moarvm.org/measurements/perl6-bench/
10:08 zakharyas joined #moarvm
10:41 cognominal joined #moarvm
12:02 timotimo i noticed i haven't actually merged the "only use atomic ops when more than one thread exists" code yet. maybe i should.
12:02 timotimo perhaps i should wait for after february's release, though?
12:03 jnthn That's still a bit into the future
12:04 flussence .oO( will the february release even be in february? )
12:04 timotimo OK, then i'll do it later today
12:04 jnthn flussence: Dunno, that sounds terribly conventional :P
12:06 timotimo maybe next year we'll use discordian "months" instead of the regular ones
12:06 timotimo well, in the discordian calendar we only have 5 seasons, which is the equivalent of months
12:07 jnthn .oO( accordian months sound better to me... :) )
12:07 timotimo chaos, discord, confusion, bureaucracy, and "The Aftermath" ♥
12:07 timotimo "This is Rakudo Chaos 3182"
13:17 Ven joined #moarvm
13:40 Ven joined #moarvm
13:52 Ven joined #moarvm
14:06 masak joined #moarvm
14:07 masak dunno how relevant this is, but it reminded me of MoarVM for some reason: https://webkit.org/docs/b3/
14:09 jnthn Hm, interesting
14:10 leont joined #moarvm
14:11 japhb joined #moarvm
14:30 kjs_ joined #moarvm
14:52 brrt joined #moarvm
14:52 brrt ohai
14:52 timotimo oh, hey brrt
14:52 timotimo how's your day? :)
14:52 brrt masak: yeah, b3 and expr jit are similarish, except that b3 is of course written by experts people who know what they're doing, and expr jit is written by me
14:53 brrt hmm, okay i guess
14:54 brrt jnthn: i recall fixing that cleanup on the jitcode earlier
14:54 brrt but maybe that was limited to the expr jit branch
15:05 brrt also, b3 doesn't do 'optimal' tiling but maximal-munch
15:05 brrt which is a good way, fwiw
15:12 brrt recording a 'good idea' here; i was thinking of creating a table of  { operation, { operand_nr, operaand_type }, template } for type-specific operation templates
15:15 vendethiel joined #moarvm
15:23 Ven joined #moarvm
15:24 brrt (and yes, i will eventually get to implementing all these things :-))
15:28 Ven joined #moarvm
15:30 brrt anyway, that would be used for specialized jit templates
15:33 japhb joined #moarvm
15:41 vendethiel joined #moarvm
16:02 masak brrt: yes, the greedy approach seems like it could work quite well
16:45 leont joined #moarvm
17:05 timotimo jnthn: something may be off in our "dead BB elimination", i have an example for you: https://gist.github.com/timo/6e049585004912f5f24d
17:06 timotimo even the very simple code perl6 -e 'for ^4194304 { rand }' ends up not inlining the loop body (but it does inline rand)
17:07 jnthn Loop bodies are map closures at present so don't really inline at all
17:07 timotimo oh
17:07 timotimo OK, fair enough
17:07 jnthn Hm, you mean BB4 is unreachable, but left behind?
17:08 timotimo i think so, yes
17:08 timotimo Successors: 5
17:08 timotimo Predeccessors: 5
17:08 timotimo ^- very suspicious
17:09 timotimo also, that for loop gets turned into a while loop; wouldn't that make it inlinabler?
17:10 timotimo in the profile, i get 67.5% exclusive time on the outer block, the one that for's, and 32.5% exclusive time on the inner block, the one that rand's
17:10 timotimo so ... rand is really fast, but entering a block and incrementing an integer is really slow in comparison?
17:11 jnthn Something like
17:11 jnthn Invocation is fairly high on my list of stuff to speed up
17:12 timotimo sweet
17:13 timotimo i'm not really aware what exactly makes invocation expensive
17:18 timotimo do you have a clue how much you can get out of optimized invocation?
17:19 jnthn Not sure, but it can account for up to 10% of runtime in some cases on profiles.
17:19 jnthn But we also have GC getting costly when there's huge numbers of closures alive
17:19 timotimo mhm
17:24 FROGGS joined #moarvm
18:08 japhb joined #moarvm
18:21 diakopte1 I saw fixed size allocation taking up 6% of the 10% of invocation
18:21 diakopte1 well, 60% depending how you read it
18:22 timotimo oh? wow
18:22 diakopte1 (using Xcode's profiler)
18:22 timotimo was that what we had the frame cache for at some point?
18:23 diakopte1 yeah, but theoretically the fixed size allocoater should be good too
18:23 diakopte1 alligoater
18:25 timotimo i haven't looked at the FSA yet ... does it have a lot of locking or something?
18:26 diakopter no, but the malloc it calls probably does in most platforms
18:26 timotimo ah
18:26 timotimo but don't we have a bunch of pools for that purpose? with like big pages?
18:27 diakopter there might be some arithmetic wrong somewhere; last time I looked (within 2 months) the number of mallocs seemed quite high compared to number of calls to the FSA
18:27 timotimo hmm
18:28 timotimo well, there's a whole bunch of straight-up malloc calls from deserialization
18:28 timotimo for STables, iirc
18:34 vendethiel joined #moarvm
18:39 japhb joined #moarvm
18:58 japhb joined #moarvm
19:03 japhb Oh holy cow, timotimo++ did a pile of fixes for perl6-bench!
19:03 japhb Very many thanks to both of you for keeping it going.  :-)
19:04 timotimo <3
19:20 domidumont joined #moarvm
19:24 jnthn The improvements should show up in tonight's run
19:25 timotimo when is that likely to appear online? do you have to manually upload the result?
19:25 jnthn timotimo: No, it's an automated run
19:25 timotimo cool :)
19:26 timotimo i'm looking forward to that
19:26 jnthn So I don't have to do anything for it to run. Do have to `git pull` in improvements still
19:27 jnthn (Not for Rakudo etc., just for the benchmarks themselves)
19:27 jnthn It runs with Rakudo and NQP HEAD and the Moar in MOAR_REVISION
19:31 timotimo ah, hm. so only benchmark improvements, no moar improvements just yet
19:34 diakopter .oO( I wonder if the cache_sc_idx branch automagically fixed itself on windows... I'll check )
19:34 timotimo i'm running spec tests with the no-atomics-for-stuff merge
19:40 cognominal joined #moarvm
19:40 dalek Heuristic branch merge: pushed 48 commits to MoarVM/cache_sc_idx by diakopter
19:40 diakopter dalek++ # for once
20:06 [Coke] even a stopped bot is right twice a...
20:30 zakharyas joined #moarvm
20:34 timotimo it seems like all those spec tests are busy-looping inside an AO_ operation
20:48 dalek MoarVM: 2136293 | jnthn++ | src/core/nativecall_ (2 files):
20:48 dalek MoarVM: Don't create partly-initialized callsites.
20:48 dalek MoarVM:
20:48 dalek MoarVM: We left the named args pointer junk, which would cause problems were
20:48 dalek MoarVM: it freed later. Would only have come up with --full-cleanup before,
20:48 dalek MoarVM: but after fixing a leak in callsite interning it could come up much
20:48 dalek MoarVM: more often.
20:48 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/2136293933

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