🦋 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: ... | Logs available at irclogs.raku.org/raku-dev/live.html | For MoarVM see #moarvm
Set by lizmat on 8 June 2022.
00:00 reportable6 left 00:02 reportable6 joined 01:18 ab5tract left 01:56 MasterDuke joined 03:38 reportable6 left, quotable6 left, bisectable6 left, benchable6 left, tellable6 left, coverable6 left, bloatable6 left, unicodable6 left, nativecallable6 left, linkable6 left, shareable6 left, statisfiable6 left, evalable6 left, notable6 left, squashable6 left, sourceable6 left, committable6 left, greppable6 left, releasable6 left, reportable6 joined, statisfiable6 joined 03:39 nativecallable6 joined, coverable6 joined, linkable6 joined, benchable6 joined, sourceable6 joined 03:40 committable6 joined, greppable6 joined, bisectable6 joined, unicodable6 joined, evalable6 joined, quotable6 joined 03:41 notable6 joined, tellable6 joined, squashable6 joined, releasable6 joined, shareable6 joined, bloatable6 joined 06:00 reportable6 left 06:01 reportable6 joined 06:07 samcv_ joined 06:12 heartburn left, samcv left, timo left, [Tux] left 06:19 [Tux] joined, timo joined 06:21 heartburn joined 09:52 |Tux| left, tbrowder__ left, rba left, leont left 10:04 |Tux| joined, tbrowder__ joined, rba joined, leont joined
guifa_ right, but I mean, are the values of the hash also values of the array? Or are they distinct sets of values? 11:17
sounds like more the latter
12:00 reportable6 left 12:01 reportable6 joined 12:08 squashable6 left 12:11 squashable6 joined 12:24 ab5tract joined 12:31 samebchase left 12:32 samebchase joined 12:43 ab5tract left
Geth rakudo/main: 99a0107562 | (Elizabeth Mattijsen)++ | src/core.c/Any-iterable-methods.pm6
Make Any.iterator-and-first an implementation detail

rather than a private method. Also use $foo is rw for a writable positional, and remove the superfluous "is raw" on the method.
Looks like this makes .min about 1% faster. Also done in preparation for more optimizations.
13:23
rakudo/main: 1579da00aa | (Elizabeth Mattijsen)++ | 2 files
Optimize .min/.max/.minmax/.minpairs/.maxpairs

  - .min / .max about 30% faster
  - .minmax about 20% faster
  - .minpairs / .maxpairs about 10% faster
These speed improvements were possible because the code for these ... (5 more lines)
13:28 Ven_de_Thiel joined 13:34 NemokoschKiwi joined 13:36 NemokoschKiwi left 14:17 vrurg_ is now known as vrurg
Geth rakudo/main: ec0007729d | (Elizabeth Mattijsen)++ | src/core.c/Order.pm6
Implement .min|max :k :v :kv :p
14:20
14:24 Ven_de_Thiel left 14:29 Ven_de_Thiel joined 14:33 Xliff joined
vrurg lizmat: so, let's have it here. 14:36
14:36 Ven_de_Thiel38 joined
lizmat fwiw I also did some cleanup / removed deprecations / update docs and test, so it was not work thrown away :-) 14:37
14:37 Ven_de_Thiel left
vrurg I hope so. :) Anyway, it would actually be even better if referring a lowered lexical dynamically would de-optimize it. Not sure how feasible is this. 14:39
lizmat but that's the thing about lowered lexicals, you can't unlower them, because that info is lost is it not ? 14:41
[Tux] Rakudo v2023.06-198-gec0007729 (v6.d) on MoarVM 2023.06-4-g75fe055c2
csv-ip5xs0.916 - 1.054
csv-ip5xs-205.219 - 6.041
csv-parser4.093 - 4.175
csv-test-xs-200.422 - 0.452
test6.453 - 6.882
test-t1.356 - 1.744
test-t --race0.844 - 1.052
test-t-2020.291 - 21.743
test-t-20 --race6.958 - 7.309
14:46
vrurg lizmat: I never was into the details. But have a hope that even if this is true the information could be stashed away for later and re-used if necessary. The question is what'd be the memory cost of this. 14:49
Geth rakudo/main: dbb95d1fea | (Elizabeth Mattijsen)++ | 3 files
Introduce Range.Inf-Inf implementation detail method

Returns the Inf .. -Inf range, aka the range that never matches anything. This is returned in many case: by making it a method without arguments makes for smaller bytecode and earlier inlining.
Making it return a compile-time value, should be beneficial at runtime.
14:53
rakudo/main: 8157c0335c | (Elizabeth Mattijsen)++ | src/core.c/Order.pm6
Abstract comparator logic

For better maintainability, and smaller bytecode in the hot parts
15:10
15:12 Ven_de_Thiel38 left 15:40 Ven_de_Thiel joined
Geth rakudo/main: 4645317d7b | (Elizabeth Mattijsen)++ | src/core.c/Order.pm6
Implement .(min|max)pairs(&by) + (min|max)(&by, :foo)

So all permutations of .min / .max / .minpairs / .maxpairs can now specify a custom comparator. Including the .min / .max cased with adverbs such as :k, :kv, :v, :p
15:48
Ven_de_Thiel
.oO( sort(:k) would basically make it an APL sort )
15:59
lizmat yeah, look at that atm 16:04
Ven_de_Thiel mh, that's ;vsp
oops
lizmat *looking
Ven_de_Thiel I guess the easiest impl would use a Schwartzian transform 16:14
m: sort-idx(@a) { @a.map({ $++ => $_ }).sort(*.value).map(*.key) }; my @ary = 1, 3, 2; my @idx = sort-idx(@ary); say @idx; say @ary[@idx]; 16:15
camelia ===SORRY!=== Error while compiling <tmp>
Variable '@a' is not declared. Perhaps you forgot a 'sub' if this was
intended to be part of a signature?
at <tmp>:1
------> sort-idx(⏏@a) { @a.map({ $++ => $_ }).sort(*.value
Ven_de_Thiel m: sub sort-idx(@a) { @a.map({ $++ => $_ }).sort(*.value).map(*.key) }; my @ary = 1, 3, 2; my @idx = sort-idx(@ary); say @idx; say @ary[@idx];
camelia [0 2 1]
(1 2 3)
Ven_de_Thiel not the most performant, of course :-)
well, it should be called grade if taking after APL 16:16
lizmat Ven_de_Thiel: if you use a mapper with sort, it already does a Schwartzian transform under the hood 16:17
:k would just need to force that and expose the indices
with just being the appropriate amount of SMOP 16:18
Ven_de_Thiel lizmat: I know, but I want the... "opposite" of a Schwartzian transform here
lizmat yeah, got that 16:19
Ven_de_Thiel (unsure what SMOP means)
lizmat Simple Matter Of Programming 16:20
Ven_de_Thiel ah, the partner to a round tuit
17:09 Ven_de_Thiel left, Ven_de_Thiel joined 17:23 Xliff left
lizmat vrurg do we have a way to change an nqp::list_i into a native int array ? 17:27
apart from iterating and copying
18:00 reportable6 left 18:02 Ven_de_Thiel left, reportable6 joined 18:18 Ven_de_Thiel joined 18:39 Ven_de_Thiel left
vrurg lizmat: I think there is no other way. They are different reprs. 18:47
19:02 ab5tract joined 19:15 Ven_de_Thiel joined 19:18 ab5tract left
Geth rakudo/main: 8b4aca57a6 | (Elizabeth Mattijsen)++ | src/core.c/List.pm6
Streamline List.sort a bit

  - use ternaries instead where possible
  - abstract reification logic in a private method
In preparation for new features.
19:29
19:32 Ven_de_Thiel left
lizmat notable6: weekly 19:34
notable6 lizmat, 2 notes: 2023-08-08T15:34:57Z <lizmat>: news.ycombinator.com/item?id=37040681 ; 2023-08-08T15:34:59Z <lizmat>: lobste.rs/s/x5impj/raku_language_for_gremlins
20:48 Ven_de_Thiel joined
japhb lizmat: If you do end up figuring out changes that make native arrays more amenable to memcopy, please let me know -- CBOR-Simple spends an inordinate amount of energy trying to make copying of native arrays as fast as possible, and it's basically a giant mash of custom nqp::while loops. 21:10
(Mind you, even without a memcopy version, slinging packed native arrays in CBOR-Simple is one of the fastest operations on a per-element basis. But it's also one that's likely to be an actual performance hotspot in real-world use cases, so worth every bit of performance I can throw at it.) 21:12
21:25 ab5tract joined 22:02 Ven_de_Thiel left 22:11 ab5tract left 22:56 ab5tract joined 23:08 ab5tract left