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