Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2017-12-05

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

All times shown according to UTC.

Time Nick Message
00:10 jnthn joined #moarvm
00:55 patrickz_ joined #moarvm
00:59 evalable6 joined #moarvm
02:16 TimToady joined #moarvm
02:57 Voldenet joined #moarvm
02:57 Voldenet joined #moarvm
02:59 ilbot3 joined #moarvm
02:59 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
03:25 Voldenet joined #moarvm
03:25 Voldenet joined #moarvm
04:29 samcv joined #moarvm
04:51 BinGOs joined #moarvm
06:04 releasable6 joined #moarvm
06:04 greppable6 joined #moarvm
06:05 squashable6 joined #moarvm
06:17 AlexDaniel joined #moarvm
06:39 brrt joined #moarvm
07:09 brrt joined #moarvm
07:11 domidumont joined #moarvm
07:16 geospeck joined #moarvm
07:16 domidumont joined #moarvm
07:35 reportable6 joined #moarvm
07:47 brrt joined #moarvm
08:08 lizmat joined #moarvm
09:45 lizmat jnthn: re making let/temp use IterationBuffer: https://gist.github.com/lizmat/155cc1e437f9abbd3e9421054b603099
09:46 lizmat alas, this does not do the trick: MVMArray: Can't shift from an empty array
09:46 lizmat am I missing something?
09:46 lizmat afk for a few hours&
10:13 jnthn lizmat: Apparently, though I've no guesses about what just looking at the patch.
10:19 lizmat ok, thanks for the sanity check
10:20 lizmat apparently I'm not going to be away for a few hours after all
10:38 lizmat m: use nqp; my $a := nqp::create(IterationBuffer); Nil while $a   # the reason
10:39 camelia rakudo-moar 78aeaf469: OUTPUT: «(timeout)»
12:57 lizmat jnthn: just wondering, is there a reason why "my %h = a => 42; %h.AT-KEY("a") for ^10000000" should not get inlined ?
12:59 * lizmat means the call to Hash.AT-KEY of course :-)
13:09 * dogbert17 has made some updates to https://github.com/MoarVM/MoarVM/issues/754
13:18 arnsholt joined #moarvm
13:20 jnthn lizmat: Yeah, we need to split AT-KEY into a small method that returns the value if the key is ther, and a private method that has the auto-viv closure
13:21 jnthn lizmat: We can inline a call *to* a closure. We can't inline something that *takes* a closure.
13:21 lizmat oki
13:21 lizmat gotcha
13:21 jnthn Same for AT-POS in Array fwiw
13:22 lizmat yup
13:22 lizmat will take that on
13:22 jnthn I don't know if we ever can inline something that takes closures
13:22 jnthn Because the ->outer of the captured code object needs a MVMFrame to point at
13:22 jnthn Unless we somehow make that MVMFrame + index, but I suspect there's a lot of trickiness there
13:35 lizmat ooh, wow, it's now gotten so smart that in a 10M loop, it just stops calling AT-KEY after about 10K times
13:35 lizmat my %h = a => 42; %h.AT-KEY("a") for ^10000000  # jnthn: could that be possible ? ^^^
13:38 jnthn Just stops calling it? :)
13:38 lizmat well, in --profile it looks like
13:39 lizmat only 9832 calls to Hash.AT-KEY, and mostly red
13:40 lizmat otoh there's a <anon> with 19990168 calls, which is 2M - 9832
13:40 lizmat so I guess it's some --profile artefact
13:41 lizmat fwiw, this makes AT-KEY about 1.7x as fast in this benchmark
13:42 lizmat let's see if it survives spectest  :-)
13:55 jnthn It should give you an inline ratio also on the first summary page
14:02 lizmat "Inlining eliminated the need to create 9990168 call frames (that's 33.3%)."  :-)
14:03 lizmat hmmm... although the % seems to be off:
14:03 lizmat In total, 20009857 call frames were entered and exited by the profiled code. Inlining eliminated the need to create 9990168 call frames (that's 33.3%).
14:03 lizmat m: say 9990168 / 20009857
14:03 camelia rakudo-moar f6c2e70bb: OUTPUT: «0.499262339␤»
14:04 lizmat m: say (20009857  + 9990168) / 20009857
14:04 camelia rakudo-moar f6c2e70bb: OUTPUT: «1.499262339␤»
14:04 lizmat ok, like that  :-)
14:15 jnthn yes :)
14:17 dogbert17 more more :)
14:32 lizmat jnthn: looks like Array.AT-POS already abstracted container creation into a separate private method
14:48 jnthn Ah, OK
14:52 lizmat hmmm.. still, AT-POS is not getting inlined :-(
14:52 * lizmat looks again
14:53 lizmat jnthn: ah, probably the $*INDEX ?
14:57 jnthn lizmat: At the top of src/spesh/optimize.c there's a
14:57 jnthn #define that you can uncomment
14:58 jnthn uh, not uncomment
14:58 jnthn But turn from 0 to 1
14:58 jnthn It dumps out on stderr why it could or couldn't inline things
14:58 timotimo which AT-POS are we looking at?
14:58 timotimo since there's multiple multis
14:58 lizmat Array.AT-POS
14:58 jnthn Just tweak it and then make -j install in the MoarVM folder. No need to rebuild NQP or Rakudo
14:59 timotimo looking up a dynamic var shouldn't prevent inlining, or should it?
15:00 jnthn Shouldn't
15:00 jnthn Even declaring one wouldn't
15:01 timotimo could the my $todo prevent it?
15:03 jnthn oh...what
15:03 jnthn That method is giant
15:03 lizmat yeah, looking at making the common case smaller  :-)
15:03 timotimo hm, yeah, there's many invocations, those each cost a couple of instructions
15:04 jnthn Yeah, I bet it's over the size limit
15:04 * lizmat is working on making the common case smaller :-)
15:06 brrt joined #moarvm
15:09 timotimo maybe CArray can also get a little pass looking at inlinability
15:42 zakharyas joined #moarvm
15:49 zakharyas joined #moarvm
15:54 zakharyas joined #moarvm
16:03 zakharyas joined #moarvm
16:06 domidumont joined #moarvm
16:11 zakharyas joined #moarvm
16:31 zakharyas joined #moarvm
17:06 zakharyas joined #moarvm
18:29 Ven`` joined #moarvm
19:36 unicodable6 joined #moarvm
19:36 bisectable6 joined #moarvm
19:36 committable6 joined #moarvm
20:33 benchable6 joined #moarvm
21:05 zakharyas joined #moarvm
21:32 TimToady joined #moarvm
22:48 AlexDaniel joined #moarvm

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