AlexDaniel` “no ssd” option is going to be too slow I think 01:34
“Why is docker necessary?” oh god.
I've been running the bots as systemd services, it's terrible 01:35
I did that because 1. docker wasn't that much popular at the time and 2. because I couldn't be bothered to spend 20 minutes writing a dockerfile 01:36
don't be like me
it'll resolve several long-standing issues with the bots 01:38
06:27 oem left 06:36 oem joined 07:58 cog joined 08:01 oem left 08:02 cog__ left 09:15 Altai-man joined
Geth nqp: de93c668c6 | (Elizabeth Mattijsen)++ | tools/templates/MOAR_REVISION
Bump MoarVM for latest fixes
 11:21
rakudo: 7c37d922fc | (Elizabeth Mattijsen)++ | tools/templates/NQP_REVISION
Bump NQP to get the latest MoarVM fixes
 11:32
11:57 sena_kun joined 11:58 Altai-man left 12:02 gugod left
Geth rakudo/faster-slice-access: 1628a630a7 | (Elizabeth Mattijsen)++ | 3 files
Make @a[Int]:adverbs between 2x and 6x as fast

Introducing Array::Element class and Array::Element::xxx classes for faster dispatch and direct handling of adverbs using the new adverb handling infrastructure. Also contains some other tweaks.
This breaks some spectests that look for less specific error messages ... (5 more lines)		 12:16
timotimo whoa 12:25
Geth rakudo/faster-slice-access: 0cad82b35c | (Elizabeth Mattijsen)++ | src/core.c/array_slice.pm6
Restore bare @a[Int] candidate

This was somehow lost, but vary well cared for by the @a[Any] candidate, but having a bare @a[Int] candidate *is* better in the short run. In the long run it would all get optimized in (almost) the same way anyway.		 12:32
[Tux] Rakudo v2020.12-10-g7c37d922f (v6.d) on MoarVM 2020.12-9-gb8663f53a
csv-ip5xs0.845 - 0.948
csv-ip5xs-208.324 - 9.189
csv-parser27.386 - 31.220
csv-test-xs-200.425 - 0.451
test7.529 - 9.183
test-t2.083 - 2.313
test-t --race0.906 - 0.924
test-t-2035.029 - 36.024
test-t-20 --race10.191 - 10.948
 12:55
Geth rakudo/faster-slice-access: 6c36067478 | (Elizabeth Mattijsen)++ | 2 files
Rince, repeat for the @a[Any] case

Makes the @a[Any]:adverbs case about 2x as fast.		 13:25
dogbert17 lizmat: is anything special needed in order to build the faster-slice-access branch? 13:40
+++ Compiling blib/Perl6/Metamodel.moarvm 13:41
lizmat you need to run configure again
dogbert17 +++ Compiling blib/Perl6/BOOTSTRAP/v6c.moarvm
make: *** No rule to make target 'src/core.c/Array/Element.pm6', needed by 'blib/CORE.c.setting.moarvm'. Stop.
I have run 'perl Configure.pl --gen-moar --gen-nqp --backends=moar'
lizmat argh,.,, did I forget to push Array/Element ?
dogbert17 impossible :) 13:42
Geth rakudo/faster-slice-access: 6400152b3f | (Elizabeth Mattijsen)++ | src/core.c/Array/Element.pm6
Oops, forgot to push Array::Element

  dogbert17++ for the spot!
[Tux] Rakudo v2020.12-10-g7c37d922f (v6.d) on MoarVM 2020.12-9-gb8663f53a
csv-ip5xs0.840 - 0.881
csv-ip5xs-208.094 - 8.142
csv-parser28.064 - 29.532
csv-test-xs-200.384 - 0.389
test8.101 - 8.218
test-t1.989 - 2.001
test-t --race0.846 - 0.977
test-t-2031.951 - 33.282
test-t-20 --race9.410 - 9.755
 14:18
(the first one ran during some relatively heavy network traffic as I noticed when that was done)
dogbert17 m: my @a = ("a" .. "za")[*]; say @a[(^@a).pick]; say @a.elems; say now - INIT now 14:21
camelia tu
677
6.1435179
14:21 gugod joined
lizmat dogbert17: why not @a.pick ? 14:22
m: my @a = ("a" .. "za")[*]; say @a.pick; say @a.elems; say now - INIT now
camelia gv
677
5.8618448
lizmat m: my @a = ("a" .. "za")[*]; say @a.pick; say @a.elems; say now - INIT now
aaah... the whatever slice
camelia vc
677
6.03103091
dogbert17 lizmat: I stole the example from github.com/rakudo/rakudo/issues/3865 14:23
lizmat dogbert17: that slowness of assigning to the Whatever slice will sool be gone 14:30
*soon
seems like the Whatever slice on a Sequence sorta triggers a worse case scenario 14:33
the code without the [*] has 0 GC's, the one with has 248 GC's :-( 14:34
with Str.succ called 229502 times instead of 677
wtf ?
brrr...
timotimo i think i saw that before 14:38
for some reason it starts over and over again
from the beginning
lizmat yeah... looks like 14:40
maybe I should revisit my Sequence work some day soon 14:41
dogbert17 that succ(s) :) 14:42
timotimo i'm hoping this can be improved without redoing sequence :D
lizmat actually, it's not a Seq, it's a Range :-) 14:52
timotimo true 14:56
Geth rakudo: 9ad80af215 | (Elizabeth Mattijsen)++ | src/core.c/array_slice.pm6
Speedup the basic @a[*] (Whatever slice)

Spotted by Jan-Olof Hendig++ with my @a = ("a" .. "za")[*]. That particular example is now about 80x as fast, but bigger sources in number of elements will probably see even better improvements as the original situation appears to have iterated the Range again and again for each element fetched.		 15:35
lizmat dogbert17 timotimo ^^
MasterDuke hey, now i can't use that example as a pathological deopt test case! 15:48
lizmat m: my $r := "a" .. "za"; my @a = $r[^$r.elems]; say now - INIT now 15:53
camelia 6.21456879
lizmat MasterDuke: ^^
15:56 Altai-man joined 15:58 sena_kun left 15:59 domidumont left, domidumont joined
MasterDuke ha 16:01
dogbert17 lizmat++, doesn't that mean you can move R#3865 to testneeded? 16:30
linkable6 R#3865 [open]: github.com/rakudo/rakudo/issues/3865 [performance] Slow code when using whatever star in index to return full-length object (who'da thunk?)
lizmat dogbert17: looks like 16:31
Geth rakudo/faster-slice-access: a3ef39a51d | (Elizabeth Mattijsen)++ | src/core.c/array_slice.pm6
Make bare @a[*-1] about 30% faster

Perform more checks locally. Als add a Failure:D candidate for handling @a[foo][bar] where the results of @a[foo] would be a Failure.		 16:59
18:23 domidumont left 19:26 b2gills left 19:55 b2gills joined 19:57 sena_kun joined 19:59 Altai-man left 20:38 leont joined 21:22 sena_kun left
Geth rakudo: 4c91d743af | (Elizabeth Mattijsen)++ | 4 files
Remove a lot of unnecessary int $pos candidates

of (AT|ASSIGN|BIND|EXISTS|DELETE)-POS candidates. These candidates were once written with the assumption that using a native integer on a candidate with a native int "receiver", would be more efficient. It currently isn't, it's even (much) slower than having a native integer on an Int "receiver".
Also, turned out that Array.DELETE-POS(Int) was deferring to the Array.DELETE-POS(int) candidate. By making that the Int candidate and removing the int candidate, DELETE-POS is now about 7% faster.		 21:31
rakudo/faster-slice-access: 15 commits pushed by (Elizabeth Mattijsen)++
review: github.com/rakudo/rakudo/compare/a...a5885d9d1f		 21:38
lizmat just a rebase
Geth rakudo/faster-slice-access: da7d256a96 | (Elizabeth Mattijsen)++ | src/core.c/array_slice.pm6
Correctly fast-path the bare whatever slice
 23:04
23:18 rypervenche left
Geth rakudo/master: 7 commits pushed by (Vadim Belman)++ 23:36
23:41 rypervenche joined 23:48 leont left

Powered by Cro and the Raku® Programming Language.

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

Thank you!