Welcome to the main channel on the development of MoarVM, a virtual machine for NQP and Rakudo (moarvm.org). This channel is being logged for historical purposes.
Set by lizmat on 24 May 2021.
vrurg I have some pretty interesting benchmarking here: github.com/Raku/problem-solving/issues/334 01:42
timo giving Cdefault an int32 attribute makes it a little faster even 01:56
if you replace |c with :$n it's a lot faster than Cdefault 01:59
0.723379992 | 0.473043493 02:00
this is with :$n, :$m
Voldenet it's a bit surprising that `Cnew.new(:$n)` is faster than `Cnew.new(int32 :$n)` 02:05
though it's `0.634931815 | 0.330936486` vs `0.645507507 | 0.386812083` 02:07
not substantial difference
timo do we have literally SET-SELF(|c) in much of our code? i assume it's the capture that costs the most here 02:09
Voldenet from what I see SET-SELF always uses positional args 02:14
and it consistently beats everything else 02:18
timo named and positional are supposed to have the same performance after spesh 02:26
japhb timo: Would that still be true given newdisp? I would expect positional args would be *very* fast in new-disp, especially handed from routine to routine in the same order 02:37
timo you mean the thing about |c? 02:41
/bin/time raku -e 'for ^50_000_000 -> int $_ { my int $a = $_ div 2; $a = $_ div 4; $a = $_ div 8; $a = $_ div 16; $a = $_ div 32; $a = $_ div 64; $a = $_ div 128; $a = $_ div 256 }'
i timed this at 1.25s with my div-to-brshift branch and 4.8s without
japhb: all i know is when i switched the |c out for explicit arguments, it got a whole lot faster 02:45
timo now imagine the improvement we could get if we take the techniques from libdivide for non-power-of-two divisions and modulus as well 02:58
though the win won't be as extreme perhaps? 02:59
" libdivide's scalar code is up to 16 times faster for powers of 2, 10 times faster for non-powers of 2, compared to naive hardware division." 03:01
japhb timo: I was talking about explicit positional args, not captures. 06:36
I'm actually surprised that brshift is so much faster *at the Raku level*. I honestly would have expected our overhead to hide that. Or maybe brshift makes it all the way down to the JIT? 06:37
Nicholas good *, japhb 06:40
good *, *
nine brshift on native integers is JITed indeed 07:13
Becomes mov rax, WORK[reg_b]; mov cl, byte WORK[reg_c]; sar rax, cl; mov WORK[reg_a], rax; 07:14
nine I think the massive difference is not actually in how shifting is faster than dividing in hardware but that even the JITed version of div_i has to check for division by 0 and handle negative divisors 07:22
Kaiepi i got sick of not being able to do like 08:07
LAPTOP-7I9RCT0C% raku -e 'my constant F = Semaphore.new: 42; use nqp; say nqp::unbox_u(F)'
42
so i'm trying my hand at eliminating libuv from the Semaphore REPR 08:08
since it's missing basic features like sem_getvalue
timo cool 10:15
nine Just noticed that we've got 2 spec test failures with blocking and nodelay: not ok 126 - Accessing non-existing on num32 array dies, not ok 237 - Accessing non-existing on num64 array dies 16:04
Nicholas IIRC there are two regular spectest fails on master with blocking and something. But I don't know enough to fix them 16:06
Geth MoarVM/fallback_resolver: a6fbcf6b7f | (Stefan Seifert)++ | 12 files
Support a fallback resolver when looking for dynamic variables
 16:07
MoarVM/fallback_resolver: 35064bf9a3 | (Stefan Seifert)++ | 7 files
Support fallback resolver in getlexouter
MoarVM/fallback_resolver: c89c3ec898 | (Stefan Seifert)++ | 10 files
Support fallback resolver in *getlex*
vrurg m: start loop {}; await start { sleep 1; note "OK"; } 21:43
Something is deeply wrong here.
camelia (timeout)
vrurg How come a deep loop in one thread doesn't let complete a promise in another? 21:44
bisectable6: start loop {}; await start { sleep 1; note "OK"; } 21:45
bisectable6 vrurg, Will bisect the whole range automagically because no endpoints were provided, hang tight
vrurg, Output on all releases: gist.github.com/27fac2aab893f77bbf...8b53efe9f9 21:47
vrurg, Bisecting by exit signal (old=2021.09 new=2021.10). Old exit signal: 0 (None) 21:48
vrurg, bisect log: gist.github.com/732f506a6fe9c2f134...95a96eced2 21:52
vrurg, Output on all releases and bisected commits: gist.github.com/dc566bbda2ecb568b8...c783cfcd7a
vrurg bisectable6: good=2021.09 bad=2021.10 start loop {}; await start { sleep 1; note "OK"; } 21:57
bisectable6 vrurg, Bisecting by exit signal (old=2021.09 new=2021.10). Old exit signal: 0 (None)
bisectable6 vrurg, bisect log: gist.github.com/7716535955e01b2a43...20eb592ddc 22:02
vrurg, There are 224 candidates for the first “new” revision. See the log for more details

Powered by Cro and the Raku® Programming Language.

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

Thank you!