00:05 japhb left 00:48 japhb joined 06:46 sena_kun joined 07:04 sena_kun left
lizmat m: sub a(/^foo\d/) { dd } # meh 08:22
camelia ===SORRY!===
Cannot find method 'compile_time_value' on object of type QAST::Op
lizmat feels to me we should be able to codegen this to: 08:24
m: sub a($ where /^foo\d/) { dd }; a "foo2"
camelia sub a($ where { ... })
lizmat m: sub a($ where /^foo\d/) { dd ~$/ }; a "foo2"
camelia "foo2"
ab5tract Hmm.. it seems reasonable on the one hand but also a bit too implicit on the other 08:31
Would it only be for regexen or would it support any valid where thunk? 08:32
lizmat I guess any valid where thunk 08:36
m: sub a($ where 42) { dd }; a 42
camelia sub a($ where { ... })
lizmat m: sub a(42) { dd }; a 42
camelia sub a(42)
lizmat already allowed for literals
ab5tract Maybe itā€™s almost a running joke now (I feel like itā€™s the hammer I reach for), but maybe we could add a named arg to the sub definition to enable this
Oh, thatā€™s interesting 08:37
sub s(.foo):m { ā€¦ }
But if itā€™s already there for literals, I guess that adverb is not really necessary 08:38
So it seems almost like an afterthought.. 08:40
Honestly this would be interesting to support outside of single argument subs
sub s(@a, AnEnum::A) {ā€¦} 08:41
Oops, forgot the multi
Itā€™s a lot nicer than multi s(@a, $ where AnEnum::A) {ā€¦}, in my opinion 08:42
lizmat m: sub a($a, More) { dd $a }; a 42, More 08:44
camelia 42
lizmat that already works ... :-)
falls out of smartmatching
ab5tract Wild! 08:45
m: multi s(@a, 36) { say 36 }; multi s(@a, 42) { say 42 }; s @, 36
camelia 36
ab5tract To me this looks like just a feature that was started but couldnā€™t be finished with the old compiler and dev resources
m: enum Foo <A B>; multi s(@a, Foo::A) { dd A }; multi s(@a, Foo::B) { dd B }; s @, B 08:47
camelia Foo::B
ab5tract Thatā€™s funny! I guess I didnā€™t actually try it, or else something else went wrong when I did and I misinterpreted the cause of failure 08:48
timo is now not only losing his mind because of azure windows vms, but additionally and unrelatedly also because of qemu-system 10:29
lizmat goes looking for timo's mind 10:34
Geth rakudo/main: 36e8403dc1 | (Elizabeth Mattijsen)++ | src/core.c/hash_slice.rakumod
Add dedicated { }:p|kv|k|v candidates

Not so much performance improvement, but lower bytecode size for the fast paths, so better inlining. And one step closer to getting rid of the SLICE_ONE_HASH behemoth (that once was a good optimization pre new-disp)		 10:42
rakudo/main: 753c755941 | (Elizabeth Mattijsen)++ | src/core.c/hash_slice.rakumod
Micro-opt { }:delete:exists

making it up to 7x as fast		 11:05
timo holy ... 11:10
Geth rakudo/main: e22881214e | (Elizabeth Mattijsen)++ | src/core.c/hash_slice.rakumod
Micro-opt { }:delete:(:p|kv)

making it up to 7x as fast if the key didn't exist, otherwise just smaller bytecode size so easier inlining		 11:57
timo oh, how good is our code-gen / dispatcher / whatever for coercing types in parameters? 12:02
i wonder how annoying / possible it is to use a Scalar "itself" as the key to a hash, instead of the value inside of it (now that i saw we have \key there and don't nqp::decont it 12:04
lizmat explain 12:08
timo object hashes*
lizmat ah... hmmm not seeing the advantage yet 12:09
timo m: my %foo{Scalar}; %foo{$_} = "underscore"; %foo{$/} = "slash"; .say for %foo; $_ = 9; $/ = "Hi"; .say for %foo; say %foo{$_}:p; say %foo{$/}:p;
camelia ===SORRY!=== Error while compiling <tmp>
Unsupported use of $/ variable; in Raku please use the filehandle's .nl-in attribute
at <tmp>:1
------> $/} = "slash"; .say for %foo; $_ = 9; $/ā = "Hi"; .say for %foo; say %foo{$_}:p;
timo no advantage, just something silly?
m: my %foo{Scalar}; %foo{$_} = "underscore"; %foo{$/} = "slash"; .say for %foo; $_ = 9; "Hello" ~~ /../; .say for %foo; say %foo{$_}:p; say %foo{$/}:p; 12:10
camelia Type check failed in binding to parameter 'key'; expected Scalar but got Any (Any)
in block <unit> at <tmp> line 1
timo m: my %foo{Scalar}; %foo{$_.VAR} = "underscore"; %foo{$/.VAR} = "slash"; .say for %foo; $_ = 9; "Hello" ~~ /../; .say for %foo; say %foo{$_.VAR}:p; say %foo{$/.VAR}:p;
camelia (Any) => underscore
Nil => slash
9 => underscore
ļ½¢Heļ½£ => slash
9 => underscore
ļ½¢Heļ½£ => slash
timo wheee
that's kinda cool?
lizmat hehe 12:12
but yeah.... that works
everything is an object :-)
Geth rakudo/main: eb7a8279e5 | (Elizabeth Mattijsen)++ | src/core.c/hash_slice.rakumod
Micro-opt { }:delete:exists:(:p|kv)

making it up to 7x as fast if the key didn't exist, otherwise just smaller bytecode size so easier inlining		 12:13
timo everything is an object, sure, but many places decont 12:14
12:37 nine left, nine joined
Geth rakudo/main: 49be2cf54e | (Elizabeth Mattijsen)++ | src/core.c/hash_slice.rakumod
Micro-opt { }:delete:(k|v)

making it up to 7x as fast if the key didn't exist, otherwise just smaller bytecode size so easier inlining.
Also reorganize some candidates for better maintainability		 13:09
rakudo/main: 74b45bb342 | (Elizabeth Mattijsen)++ | src/core.c/hash_slice.rakumod
Remove all SLICE_ONE_HASH references in %h<key>

They are no longer needed. Add a single candidate catching all other named arg combinations		 13:35
rakudo/main: 4646481e09 | (Elizabeth Mattijsen)++ | 2 files
Simplify %h<a b c> handling

by moving the fulfilling logic to a new .List method on the iterator		 14:14
15:04 finanalyst joined
Geth rakudo/main: 0dd0d72ee0 | (Elizabeth Mattijsen)++ | src/core.c/array_slice.rakumod
Micro-opt []:(k|p|kv|v)

Maybe a 3% faster, but more importantly much lower bytecode size, so better inlineable		 15:20
rakudo/main: b093bc42cd | (Elizabeth Mattijsen)++ | src/core.c/array_slice.rakumod
Micro-opt [x]:exists

Makes it about 25% faster and has a smaller bytecode size for better inlining		 15:42
|Tux| Rakudo v2024.08-50-gb093bc42c (v6.d) on MoarVM 2024.08-9-g570db2612
csv-ip5xs0.260 - 0.265
csv-ip5xs-201.095 - 1.112
csv-parser1.502 - 1.532
csv-test-xs-200.141 - 0.141
test1.810 - 1.815
test-t0.403 - 0.404
test-t --race0.265 - 0.268
test-t-204.792 - 4.904
test-t-20 --race1.155 - 1.181
 16:15
tux.nl/Talks/CSV6/speed4-20.html / tux.nl/Talks/CSV6/speed4.html tux.nl/Talks/CSV6/speed.log
lizmat m: sub a($a) { $a ?? 42 !! 666 }; a(True) for ^10000000; say now - ENTER now 16:29
camelia 0.23355295
lizmat m: sub a(Bool() $a) { $a ?? 42 !! 666 }; a(True) for ^10000000; say now - ENTER now
camelia 0.130698307
lizmat that feels counter-intuitive.... 16:30
Geth rakudo/main: 50b8614031 | (Elizabeth Mattijsen)++ | src/core.c/array_slice.rakumod
Micro-opt []:foo by Boolifying in the signature

This appears to make all these candidates about 3% faster. Not entirely sure why, possibly because the coercion happens at the callsite? Looks like this creates a smaller bytecode-size footprint		 16:33
16:55 finanalyst left
Geth intellij-ide-fork: ab5tract++ created pull request #1:
Merge intellij/idea/232.10335.12 to main		 17:10
ab5tract Ah, that's not actually ready yet.. I thought it was going to be internal to my own repo 17:11
Geth rakudo/main: 86a5a10cb5 | (Elizabeth Mattijsen)++ | src/core.c/array_slice.rakumod
Micro-opt [foo]:(p|kv|v)

The :p :kv candidates can *not* forward to their Int:D candidate, as they need to produce the key value unaltered.
The :v candidate forwards, and this makes it 25% faster		 17:15
ab5tract apparently it takes a bit of time to reconcile 16,000+ commits :) 17:21
lizmat is that all?
ab5tract I want to apologize for misrepresenting jnthn++ -- the .cmd files are actually some sort of wild hybrid of sh + DOS batch syntax that are supported on both platforms 17:22
lizmat: I know, I know.. amateur stuff :) 17:24
17:29 finanalyst joined 18:23 vrurg_ joined 18:26 vrurg left 18:27 vrurg joined 18:30 vrurg_ left, vrurg_ joined 18:34 vrurg__ joined, vrurg left 18:36 vrurg_ left
timo my runcy_funcy_optimizations branch makes it a tiny bit faster still 19:23
0.31113 +- 0.00280 seconds time elapsed <-- 0.51927 +- 0.00327 seconds time elapsed 19:25
that's for 50000000 runs of the loop with Bool() in the sig 19:26
lizmat nice! 19:31
timo m: say 1_758_078_934 / 50_000_000, " cpu cycles per loop iteration" 19:34
camelia 35.16157868 cpu cycles per loop iteration
timo i mean that isn't super terrible right?
ab5tract that's a nice bump indeed!
lizmat nope
ab5tract gist.github.com/ab5tract/270cf5959...c76034a561
(tl;dr -- is make install working for others?) 19:35
timo m: say 2_768_952_429 / 50_000_000, " cpu cycles per loop iteration without runcy_funcy_optimizations"
camelia 55.37904858 cpu cycles per loop iteration without runcy_funcy_optimizations
Geth rakudo/main: 045644e0a0 | (Elizabeth Mattijsen)++ | src/core.c/hash_slice.rakumod
Actually only allow concrete iterables in %h{...}
 20:04
rakudo/windows_latest_azure_pipeline: 3de00c9847 | (Timo Paulssen)++ | 2 files
try to cache moar build, it's so agonizingly slow
 21:44
rakudo/windows_latest_azure_pipeline: 4c3d6f9d43 | (Timo Paulssen)++ | azure-pipelines.yml
yeah guess what has dots in it ... dates!
 21:47
rakudo/windows_latest_azure_pipeline: 4285588c43 | (Timo Paulssen)++ | azure-pipelines.yml
now that moar has been built and cached, try building rakudo again
 22:04
timo ah crap, i guess changing the pipeline setup emptied the cache? 22:07
22:31 finanalyst 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!