MasterDuke timotimo: any thoughts why ^^^ is slower after samcv's recent change? 00:02
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
brrt good * #moarvm 07:11
brrt i'm seeing no significant difference between the bytecode for the broken and the nonbroken case 07:50
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
jnthn is the lucky one with a national holiday today 12:56
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
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
timotimo way cool 18:38
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

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!