🦋 Welcome to the IRC channel of the core developers of the Raku Programming Language (raku.org #rakulang). This channel is logged for the purpose of history keeping about its development | evalbot usage: 'm: say 3;' or /msg camelia m: ... | log inspection situation still under development | For MoarVM see #moarvm
Set by lizmat on 22 May 2021.
00:07 reportable6 left 00:10 reportable6 joined 01:55 evalable6 left, linkable6 left 02:20 vrurg joined, frost joined 02:57 linkable6 joined 03:06 frost left 03:48 vrurg left 03:49 vrurg joined 04:49 quotable6 left, squashable6 left, benchable6 left, nativecallable6 left, releasable6 left, tellable6 left, linkable6 left, notable6 left, bloatable6 left, coverable6 left, shareable6 left, bisectable6 left, committable6 left, greppable6 left, statisfiable6 left, unicodable6 left, sourceable6 left, reportable6 left, quotable6 joined, unicodable6 joined 04:50 committable6 joined, notable6 joined, releasable6 joined 04:52 bisectable6 joined, bloatable6 joined 04:56 frost joined 04:57 evalable6 joined 05:51 coverable6 joined 06:10 squashable6 joined 06:49 nativecallable6 joined 06:51 vrurg_ joined, sourceable6 joined, greppable6 joined 06:52 benchable6 joined 06:54 vrurg left 07:09 squashable6 left 07:10 reportable6 joined 07:11 squashable6 joined 07:19 frost left 07:50 linkable6 joined 07:52 tellable6 joined 08:48 frost joined 08:51 statisfiable6 joined 09:08 frost left
lizmat Files=1351, Tests=117097, 289 wallclock secs (34.98 usr 9.88 sys + 4029.97 cusr 336.74 csys = 4411.57 CPU) 09:08
Geth rakudo: 7870b446c0 | (Elizabeth Mattijsen)++ | 3 files
Fix name of Buf role generatot script
 09:12
09:51 shareable6 joined 10:08 squashable6 left
Geth rakudo: 4677dcb7ad | (Elizabeth Mattijsen)++ | 2 files
Address nine++ 's remarks on 65507b89d0602b9
 10:14
rakudo: fb25bd4e23 | (Elizabeth Mattijsen)++ | 2 files
Generate the SignedBlob/UnsignedBlob roles

So that we only need to maintain one set of code
gfldex m: my Channel:D $c.=new; start { $c.send(.item) for ^10; $c.close; } sub consumer(*@a) { say @a.shift while @a } consumer($c does Iterable); 10:23
camelia ===SORRY!=== Error while compiling <tmp>
Strange text after block (missing semicolon or comma?)
at <tmp>:1
------> rt { $c.send(.item) for ^10; $c.close; }⏏ sub consumer(*@a) { say @a.shift while
expecting any of:
…
gfldex m: my Channel:D $c.=new; start { $c.send(.item) for ^10; $c.close; }; sub consumer(*@a) { say @a.shift while @a }; consumer($c does Iterable);
camelia 0
1
2
3
4
5
6
7
8
9
gfldex I would much prefer not to have to mix Iterable into that channel. 10:24
Geth roast: d98a00bfa4 | (Daniel Green)++ | S09-hashes/objecthash.t
Make a hash whatever slice test deterministic

Otherwise there would be random fails when the values came back in different orders between runs.		 10:50
10:57 linkable6 left
gfldex m: my Channel:D $c.=new; start { $c.send(.item) for ^10; $c.close; }; sub consumer(*@a) { say @a.shift while @a }; consumer(@$c); 11:09
camelia 0
1
2
3
4
5
6
7
8
9
12:05 reportable6 left 12:10 squashable6 joined 13:07 reportable6 joined 13:59 linkable6 joined 14:03 discord-raku-bot left 14:04 discord-raku-bot joined 14:08 vrurg joined 14:10 vrurg_ left
Geth rakudo: MasterDuke17++ created pull request #4792:
Decrement # of calls in a block if any are optimized away		 14:55
15:10 linkable6 left, evalable6 left 15:12 evalable6 joined 15:13 linkable6 joined
Geth rakudo: 4d19c236a1 | (Daniel Green)++ | src/Perl6/Optimizer.nqp
Decrement # of calls in a block if any are optimized away

This unblocks more removing of magic variables (`$¢`, `$!`, `$/`, `$_`), which requires there to not be any calls in the block.
So this example `my int $a = 0; sub inc-a() { ++$a };` before would have the first three magic variables still in the block, since even though the call to `&prefix:<++>` was optimized away, the count was still non-zero. Now they are all gone.		 15:46
rakudo: fbe731521b | MasterDuke17++ (committed using GitHub Web editor) | src/Perl6/Optimizer.nqp
Merge pull request #4792 from MasterDuke17/decrement_count_of_calls_in_a_block_if_any_are_optimized_away
japhb Oooh, I wonder if that will affect [Tux]'s benchmarks 15:54
MasterDuke i doubt it. i haven't been able to craft a benchmark with a measurable runtime difference. the optimized qast is definitely better, but i think for the most part spesh is able to optimize it further regardless 15:57
lizmat but it will at least make smaller bytecode, right ? 15:58
so bigger chance of getting inlined ?
MasterDuke well, the size reported in a spesh regular log is the same. i didn't check the inline logs 15:59
do you see any difference in what you were measuring?
lizmat nope, ++$i still at 48, $i = $i + 1 at 40 16:02
ah.. oops... should pull first :-)
MasterDuke probably the `set` vs `sp_fastbox_bi_ic + return_o` is the difference, and that sadly wasn't changed by my optimization 16:04
16:07 Xliff joined
lizmat ok, confirmed: no difference 16:07
it might actually affect test-t though 16:09
I just had my first <1 second run on my machine
MasterDuke huh, that'd be cool 16:10
so both the inc and the add versions have a p6decontrv in their ast, but it's turned into a decont_i in the add version and not in the inc version 16:13
16:21 rypervenche left
MasterDuke tracking what happens in the optimizer is not terribly easy 16:34
18:06 reportable6 left 19:02 dogbert11 left 19:06 squashable6 left 19:11 dogbert17 joined
[Tux] three runs over 1.6 20:08
Rakudo v2022.02-36-gfbe731521 (v6.d) on MoarVM 2022.02-1-g0539ead63
csv-ip5xs0.869 - 0.923
csv-ip5xs-205.156 - 5.423
csv-parser4.010 - 4.015
csv-test-xs-200.411 - 0.419
test6.861 - 7.036
test-t1.609 - 1.616
test-t --race0.914 - 0.934
test-t-2023.438 - 24.222
test-t-20 --race7.380 - 7.412
20:08 reportable6 joined
MasterDuke hmmm 20:09
japhb Well that's unexpected 20:11
Geth rakudo: MasterDuke17++ created pull request #4793:
Optimize more cases of p6decontrv ops		 20:35
MasterDuke [Tux]: if you've got some time to spare, could you try with my most recent commit (4d19c236a1) reverted, and/or ^^^ PR applied? 20:36
m: my int $a = 0; sub inc-a() { ++$a }; my int $i = 0; while ++$i < 100_000_000 { inc-a(); }; say now - INIT now; say($a) 20:42
camelia 0.493754681
99999999		 20:43
MasterDuke m: my int $a = 0; sub inc-a() { $a = $a + 1 }; my int $i = 0; while ++$i < 100_000_000 { inc-a(); }; say now - INIT now; say($a)
camelia 0.494760397
99999999
MasterDuke m: my Int $a = 0; sub inc-a() { ++$a }; my int $i = 0; while ++$i < 10_000_000 { inc-a(); }; say now - INIT now; say($a) 20:49
camelia 0.35756092
9999999
MasterDuke m: my Int $a = 0; sub inc-a() { $a = $a + 1 }; my int $i = 0; while ++$i < 10_000_000 { inc-a(); }; say now - INIT now; say($a)
camelia 0.326607696
9999999
MasterDuke m: use nqp; my Int $a = 0; sub inc-a() { $a = nqp::add_I(nqp::decont($a), 1, Int) }; my int $i = 0; while ++$i < 10_000_000 { inc-a(); }; say now - INIT now; say($a)
camelia 0.292664962
9999999
japhb (I'm assuming dropping from 100M to 10M iterations was on purpose ...) 20:50
MasterDuke so for natives the runtime is pretty close between `++$a` and `$a = $a + 1`, but for bigints `++$a` is slower and going right to nqp ops is faster still than `$a = $a + 1` 20:51
yeah, just so it wasn't waiting around for 3+s per run
japhb nodnod 20:54
MasterDuke m: use nqp; my int $a = 0; sub inc-a() { $a = nqp::add_i($a, 1) }; my int $i = 0; while ++$i < 100_000_000 { inc-a(); }; say now - INIT now; say($a)
camelia 0.492337793
99999999
21:07 squashable6 joined 21:11 discord-raku-bot left 21:12 discord-raku-bot joined 21:57 qorg11 left 22:16 qorg11 joined 22:19 dogbert17 left
Geth rakudo: 2ed885238c | MasterDuke17++ (committed using GitHub Web editor) | src/Perl6/Optimizer.nqp
Optimize more cases of p6decontrv ops (#4793)

If there's a QAST::Want in a QAST::Op(p6decontrv), try to optimize based on the child of the QAST::Want. This turns the optimized version of `inc-a()` in
  `my int $a = 0; sub inc-a() { ++$a };` into essentially the same as the
optimized version of `my int $a = 0; sub inc-a() { $a = $a + 1 };`, i.e., `decont_i + assign_i + add_i` instead of `p6decontrv + assign_i + add_i`.		 22:46
22:47 linkable6 left
MasterDuke lizmat: have you done any local test-t benchmarking? 22:48
lizmat not without that last patch :)
building now
MasterDuke did you see [Tux]'s latest results?
lizmat yeah... no idea why that was 22:49
or are you suspecting 4d19c236a1ff5921a55c1da8 ?
22:50 linkable6 joined
MasterDuke yeah, there don't seem to be that many other potentially relevant commits between yesterday and today 22:51
lizmat reverted that one locally... don't see a difference, all within noise levels 22:53
MasterDuke huh, guess we'll see tomorrow 22:54
lizmat I have removed all nqp::add_i from the setting, will commit all of that tomorrow
I guess I will be changing the foo = foo + 1 to ++foo next :-) 22:55
which will make a lot of code in the setting much more readable
but first some sleep
MasterDuke wow. no change in timings?
lizmat nope... 22:56
MasterDuke cool
lizmat I think the benefit is really in the smaller memory footprint, bringing subs within inlining limit
23:21 linkable6 left, squashable6 left, reportable6 left, evalable6 left, shareable6 left, statisfiable6 left, tellable6 left, benchable6 left, greppable6 left, sourceable6 left, nativecallable6 left, coverable6 left, bloatable6 left, bisectable6 left, releasable6 left, committable6 left, notable6 left, unicodable6 left, quotable6 left, jjatria left, [Coke] left 23:23 linkable6 joined, squashable6 joined, reportable6 joined, evalable6 joined, shareable6 joined, statisfiable6 joined, tellable6 joined, benchable6 joined, greppable6 joined, sourceable6 joined, nativecallable6 joined, coverable6 joined, bloatable6 joined, bisectable6 joined, releasable6 joined, notable6 joined, committable6 joined, unicodable6 joined, quotable6 joined, jjatria joined, [Coke] 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!