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.
00:00 reportable6 left, nativecallable6 left, quotable6 left, sourceable6 left, notable6 left, tellable6 left, releasable6 left, shareable6 left, greppable6 left, bloatable6 left, ilogger2 left, harrow left 00:03 ilogger2 joined 00:06 harrow joined 00:09 reportable6 joined 00:46 greppable6 joined, releasable6 joined
vrurg I have some pretty interesting benchmarking here: github.com/Raku/problem-solving/issues/334 01:42
01:46 notable6 joined 01:47 shareable6 joined, bloatable6 joined 01:48 tellable6 joined, quotable6 joined 01:54 frost joined
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
02:48 nativecallable6 joined
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
03:48 evalable6 left, linkable6 left 03:49 evalable6 joined 03:50 linkable6 joined 03:53 sourceable6 joined 04:53 greppable6 left, shareable6 left, committable6 left, nativecallable6 left, unicodable6 left, coverable6 left, reportable6 left, quotable6 left, evalable6 left, linkable6 left, benchable6 left, statisfiable6 left, bisectable6 left, releasable6 left, tellable6 left, bloatable6 left, notable6 left 04:54 unicodable6 joined, reportable6 joined, releasable6 joined, coverable6 joined, benchable6 joined, evalable6 joined 04:55 bisectable6 joined, committable6 joined, greppable6 joined, quotable6 joined, notable6 joined 04:56 nativecallable6 joined, linkable6 joined, tellable6 joined, shareable6 joined, bloatable6 joined, statisfiable6 joined 05:56 reportable6 left, sourceable6 left, releasable6 left, committable6 left, unicodable6 left, notable6 left, bisectable6 left, bloatable6 left, nativecallable6 left, tellable6 left, shareable6 left, benchable6 left, quotable6 left, coverable6 left, greppable6 left, evalable6 left, statisfiable6 left, linkable6 left 05:57 releasable6 joined, unicodable6 joined, shareable6 joined, notable6 joined 05:58 quotable6 joined, committable6 joined, bisectable6 joined, greppable6 joined, benchable6 joined, evalable6 joined 05:59 nativecallable6 joined, linkable6 joined, bloatable6 joined, statisfiable6 joined, sourceable6 joined, reportable6 joined, tellable6 joined, coverable6 joined 06:06 reportable6 left 06:08 reportable6 joined
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
07:21 [Coke] joined
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
07:23 sena_kun joined 07:25 [Coke]_ left
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
08:29 Kaiepi left 09:29 evalable6 left, linkable6 left 09:31 linkable6 joined 09:32 evalable6 joined
timo cool 10:15
10:53 Kaiepi joined 11:06 dogbert2 joined 11:10 dogbert17 left 11:15 frost left 11:19 frost joined 11:50 dogbert2 left 11:53 dogbert11 joined 12:07 reportable6 left 12:09 reportable6 joined 13:53 vrurg_ joined, vrurg left 14:21 dogbert17 joined, dogbert11 left 14:26 ismustachio left 15:26 notable6 left, greppable6 left, statisfiable6 left, reportable6 left, evalable6 left, quotable6 left, linkable6 left, shareable6 left, coverable6 left, committable6 left, tellable6 left, nativecallable6 left, bloatable6 left, benchable6 left, sourceable6 left, releasable6 left, unicodable6 left, bisectable6 left 15:27 tellable6 joined, shareable6 joined, reportable6 joined, quotable6 joined, notable6 joined, coverable6 joined, bisectable6 joined, evalable6 joined, linkable6 joined, bloatable6 joined 15:28 sourceable6 joined, greppable6 joined, committable6 joined, releasable6 joined, benchable6 joined, nativecallable6 joined, statisfiable6 joined 15:29 unicodable6 joined 15:38 frost left
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*
16:33 dogbert11 joined 16:35 dogbert17 left 16:50 dogbert11 left 16:52 dogbert11 joined 17:05 dogbert17 joined, dogbert11 left 18:07 reportable6 left 18:09 reportable6 joined 19:09 linkable6 left, evalable6 left, linkable6 joined, evalable6 joined 19:11 vrurg_ left 19:13 vrurg joined 19:28 sena_kun left 19:29 sena_kun joined 19:36 discord-raku-bot left, discord-raku-bot joined 19:37 discord-raku-bot left, discord-raku-bot joined 20:58 sena_kun left
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)
21:58 evalable6 left, linkable6 left 21:59 linkable6 joined 22:01 evalable6 joined
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
23:01 linkable6 left, evalable6 left 23:03 evalable6 joined 23:04 linkable6 joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!