Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2017-11-17

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

All times shown according to UTC.

Time Nick Message
00:02 MasterDuke timotimo: any thoughts why ^^^ is slower after samcv's recent change?
00:12 lizmat joined #moarvm
02:08 MasterDuke callgrind shows 100m fewer instructions after (for only 100 iterations), but it's definitely slower time-wise
02:24 samcv MasterDuke: you missed where i said it was a 32 bit string
02:25 samcv so it doesn't use memset because it originates from a 32 bit string. though that test case is basically the worst possible case
02:25 samcv and shouldn't be a reason not to keep the changes. since more memcpy calls is slower, and if you do "ax" x 1_000_000 it becomes 1.5x faster than before
02:25 MasterDuke fwiw, `my str $a ...` wasn't really any better
02:26 MasterDuke i also tried "a", "ab", and "abcd" and all were slower
02:27 MasterDuke are you compiling with clang?
02:27 samcv it takes 4.0 secs with ab as oppsoed to 6.3 before
02:27 samcv (before the new changes)
02:27 samcv i'm compiling with clang
02:29 MasterDuke with gcc, "ab" takes 6.1s before, 6.5s after
02:29 samcv interesting
02:29 samcv also i get it being faster with the new code for "a"
02:29 samcv 3.17s vs 4.2s
02:30 MasterDuke for me, 3.5s before, 5.0s after for "a"
02:31 samcv gcc i get 3.17s after 2.17s before
02:31 MasterDuke are you using MVM_SPESH_BLOCKING=1?
02:31 samcv no
02:31 samcv why would i use that?
02:32 MasterDuke make spesh deterministic, so benchmarking is more repeatable
02:32 samcv ah
02:34 samcv well anyway i am working on code that will make that null and void anyway since it will memcpy for parts that it is possible and do a for loop for 8 bit strands into 32 bit flat and a for loop for repetitions
02:38 MasterDuke i get roughly the same numbers with clang
02:39 MasterDuke but you're saying i shouldn't bother investigating any more since you're working on a new optimization?
02:43 samcv well i know why it's slower. because calling memcpy 10_000_000 times 1000 times is a lot of calls
02:54 samcv for copying only 32 bits each time
02:54 samcv i guess we could be even better and fill a large piece of memory with it and then memcpy that a smaller number of times
02:54 samcv though idk if it matters that much to do that
02:56 ilbot3 joined #moarvm
02:56 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
07:10 brrt joined #moarvm
07:11 brrt good * #moarvm
07:13 domidumont joined #moarvm
07:20 domidumont joined #moarvm
07:50 brrt i'm seeing no significant difference between the bytecode for the broken and the nonbroken case
08:20 brrt joined #moarvm
08:55 domidumont joined #moarvm
09:00 brrt1 joined #moarvm
09:15 zakharyas joined #moarvm
09:42 robertle joined #moarvm
10:00 domidumont1 joined #moarvm
10:19 zakharyas1 joined #moarvm
10:27 bisectable6 joined #moarvm
10:28 zakharyas1 joined #moarvm
10:41 AlexDaniel joined #moarvm
11:41 greppable6 joined #moarvm
11:43 brrt joined #moarvm
12:26 Ven joined #moarvm
12:49 jnthn brrt: If I had to guess, it'll be something about labels and exception handler regions, given it apparently things the code in question ain't handler-covered
12:55 brrt yeah, i was stepping through it with a debugger but i had to do $dayjob then
12:55 markmont joined #moarvm
12:56 * jnthn is the lucky one with a national holiday today
13:57 zakharyas joined #moarvm
14:41 domidumont joined #moarvm
14:45 Ven joined #moarvm
15:58 markmont joined #moarvm
16:03 zakharyas joined #moarvm
16:04 domidumont joined #moarvm
16:07 domidumont joined #moarvm
16:08 brrt joined #moarvm
16:31 brrt joined #moarvm
16:31 robertle joined #moarvm
16:42 Ven joined #moarvm
16:46 brrt okay, hmm so the label that is assigned to that, in the expr jit case, is the label after the goto
16:49 brrt also,
16:49 brrt the inline_end co-occurs with the framehandler-start
16:50 brrt oh, no, it is a frame-handler end
16:52 brrt hmm, there's two inline-ends on that
16:54 brrt oh, hang on
16:54 brrt hehe
16:54 brrt bug found, fix ready
16:56 domidumont joined #moarvm
16:57 Geth ¦ MoarVM/inline-lastexpayload: 4c2823f746 | (Bart Wiegmans)++ | src/jit/label.c
16:57 Geth ¦ MoarVM/inline-lastexpayload: Fix labeling off-by-one
16:57 Geth ¦ MoarVM/inline-lastexpayload:
16:57 Geth ¦ MoarVM/inline-lastexpayload: The last 'object' label would not be counted as a instruction
16:57 Geth ¦ MoarVM/inline-lastexpayload: label (and by implication treated as a basic block label). This would
16:57 Geth ¦ MoarVM/inline-lastexpayload: cause the required label not to be setup, which would make try/catch
16:57 Geth ¦ MoarVM/inline-lastexpayload: on some frames fail.
16:57 Geth ¦ MoarVM/inline-lastexpayload: review: https://github.com/MoarVM/MoarVM/commit/4c2823f746
16:58 brrt ^ feel free to rebase or cherry-pick that on master instead
16:58 brrt .tell jnth bug is fixed
16:58 yoleaux brrt: I'll pass your message to jnth.
16:58 brrt .tell jnthn
16:58 yoleaux brrt: I don't know what you want me to say to jnthn.
16:58 brrt .tell jnthn i think the bug is fixed
16:58 yoleaux brrt: I'll pass your message to jnthn.
17:17 jnthn brrt++
17:17 yoleaux 16:58Z <brrt> jnthn: i think the bug is fixed
18:21 zakharyas joined #moarvm
18:38 timotimo way cool
18:54 committable6 joined #moarvm
18:55 committable6 joined #moarvm
18:56 committable6 joined #moarvm
18:58 committable6 joined #moarvm
19:13 AlexDaniel joined #moarvm
19:16 AlexDaniel samcv: hello :) Are you up for the release this weekend?
19:17 AlexDaniel releasable6: status
19:17 releasable6 AlexDaniel, Next release in ≈23 hours. No blockers. 109 out of 209 commits logged
19:17 releasable6 AlexDaniel, Details: https://gist.github.com/1143ad1b0eeb67443b3f7abbc29aae02
19:54 releasable6 joined #moarvm
22:18 markmont joined #moarvm
22:52 AlexDaniel joined #moarvm

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