🦋 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.
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
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)
Geth rakudo/main: ec0007729d | (Elizabeth Mattijsen)++ | src/core.c/Order.pm6
Implement .min|max :k :v :kv :p
 14:20
vrurg lizmat: so, let's have it here. 14:36
lizmat fwiw I also did some cleanup / removed deprecations / update docs and test, so it was not work thrown away :-) 14:37
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
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
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
vrurg lizmat: I think there is no other way. They are different reprs. 18:47
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
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
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

Powered by Cro and the Raku® Programming Language.

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

Thank you!