00:41 frost-lab joined 00:58 JRaspass joined 01:59 JRaspass left 02:31 kvw_5_ joined, Kaiepi left 02:34 kvw_5 left 03:02 Kaiepi joined
Geth rakudo: codesections self-assigned Wasteful convesions between Order and Bool github.com/rakudo/rakudo/issues/4238
lizmat self-assigned eefc785e0 seems to have broken YAMLish github.com/rakudo/rakudo/issues/4237
07:15 jdv79 left, jdv79 joined 08:19 sena_kun left 08:22 sena_kun joined 09:02 domidumont joined
10:09 JRaspass joined 10:22 domidumont left 10:35 JRaspass left
sena_kun japhb++ # a nice report! 10:36
10:37 domidumont joined 10:53 Kaiepi left
Geth rakudo: 70a8e3661f | (Elizabeth Mattijsen)++ | 4 files
Make sorting up to 2x as fast

Following up on a question on StackOverflow:
it turned out that checking whether an Order enum is not Same, would create a Bool object, which would then be converted to a native int. Research is going on into fixing that (bypassing the Bool object), but ... (13 more lines)
codesections lizmat++ 11:29
11:31 domidumont1 joined 11:34 domidumont left 11:40 domidumont1 left
codesections (I think "up to 2× as fast" is underselling the perf gains from ^^^^. I just benchmarked a sort based on the SO question, and saw a 4× speedup) 11:40
lizmat better like that than the other way around :-) 11:42
codesections yep! 11:43
11:45 Kaiepi joined
Geth rakudo: d61d9836ae | (Elizabeth Mattijsen)++ | 3 files
Make some more infix cmp candidates upto 7x as fast

Specifically allomorph cmp, Pair cmp and Complex cmp. This should be quite visible when sorting allomorphs, Pairs or Complex numbers.
lizmat this should be possible for more cases where cmp is called, but then we have a chicken-egg problem 12:49
in order to be able to check for Order::Same and friends, the code in the setting needs to be *after* the Order enum code
codesections hmmm 70a8e3661f seems to break sorting with custom comparators that don't return an Order.
lizmat but the Order enum code cannot exists without the Enumeration role
codesections c: 70a8e3661f say (^10).sort({$^a > $^b ?? True !! False}); say (^10).sort({$^a > $^b ?? Order::More !! Order::Less}); 12:50
12:50 linkable6 left
committable6 codesections, ¦70a8e36: «(9 8 7 6 5 4 3 2 1 0)␤(0 1 2 3 4 5 6 7 8 9)␤» 12:50
lizmat well... then they're naughty, as comparators are supposed to return an Order
codesections True. But I bet a lot out there don't (it's not enforced)
lizmat yeah, probably :-(
codesections I can take a look at how we could handle it, though 12:51
12:52 linkable6 joined
lizmat sena_kun: could you do a Blin run to check for any module testing fallout? wrt github.com/rakudo/rakudo/commit/70a8e3661f 12:53
codesections it also seems like not returning an Order is something we might want to support, though? Eg <D E F a b c>.sort({$^a.fc gt $^b.fc}) 12:57
lizmat don't know... I mean... github.com/rakudo/rakudo/commit/70a8e3661f didn't break any spectests 12:58
codesections that seems pretty clear from a dwim perspective, and works on current release
Looking at Roast, I _think_ the intent is for Bools to work. See github.com/Raku/roast/blob/master/...ort.t#L248 13:20
lizmat yeah, testing some changes :-) 13:23
it will only take the Order checking path if the Callable indicates returning an Order:D in the signature 13:34
otherwise it will take the candidate that coerces to Int (now without first coercing to Bool) 13:35
Geth rakudo: b2ae599a75 | (Elizabeth Mattijsen)++ | src/core.c/Rakudo/Sorting.pm6
Take a little bit of different approach on sorting comparators

Instead of checking for Inty return values of the comparator, and Order return values, just check for Order values being returned by the comparator, and make that take the fast nqp::eqaddr path.
Otherwise, use the old generic code path, but instead implicitely ... (6 more lines)
lizmat codesections: ^^ I think that addresses your points :-) 13:49
codesections thanks, lizmat++ If I'm reading that correctly, only subs with a `--> Order:D` _constraint_ take the ...LIST-WITH-enum path, right? 13:51
lizmat yup
codesections m: sub returns-order() { Order::Less }; say &returns-order.returns
camelia (Mu)
lizmat m: sub returns-order(--> Order:D) { Order::Less }; say &returns-order.returns 13:52
camelia (Order:D)
codesections right. So a lot of inline fns will probably take the ...WITH-int path. Which is fine, just a bit slower 13:53
lizmat yeah... now to make sure all of the builtins have the correct return sig :-)
codesections (inline fns that actually do return an Order, I mean) 13:54
haha, yeah. But this is good -- we're getting to the point where types are speeding things up, not just adding a runtime cost. Which has always been the goal 13:55
Geth rakudo: 0ad991e476 | (Elizabeth Mattijsen)++ | 2 files
Make infix before / after about 40% faster

By moving their definitions until *after* we know about the Order enum and then use the same fast-path approach as with sorting. Also slap the return signature on the proto.
14:09 finsternis left 14:30 epony left
Geth rakudo: 599b6ea5e4 | (Elizabeth Mattijsen)++ | 12 files
Add --> Order:D to protos of <=> cmp leg unicmp coll

So that using these as comparators with sorting will take the fast path. Also remove any --> Order:D from other candidates of these infixes, as they are not needed there anymore.
This caused the movement of some protos and candidates, as they should now appear *after* the Order enum has been created in the setting.
14:49 JRaspass joined
Geth rakudo: afab11e6af | (Elizabeth Mattijsen)++ | src/core.c/Rakudo/Sorting.pm6
Make --> Order:D in comparator actually take fast path

Turns out this is now only a few % faster than the "slow" path, but I guess still worth it in some situations.
14:57 frost-lab left 15:05 epony joined
Geth rakudo: 9ad4717080 | (Elizabeth Mattijsen)++ | 2 files
Fixups around infix unicmp and coll

  - Move protos to Order for clarity
  - Pair comparisons with unicmp and coll now fast-path using Order::Same
  - Add Cool candidate for unicmp, it was missing
  - On JVM, make it throw X::NYI instead of just dying
lizmat ok, so sorting with &[coll] will spend 25% of its time looking up $*COLLATION :-( 15:21
15:32 gfldex left 15:37 squashable6 left 15:40 squashable6 joined 16:13 gfldex joined
Geth rakudo: codesections++ created pull request #4240:
Add --> Order:D for Num's cmp and don't create Bools
codesections lizmat: ^^^ is basically the same as what you've been doing, and gets rid of the extra `Bool` that was the other cause of the slowdown in the SO question 16:43
Geth rakudo: 7f2dba7aee | (Daniel Sockwell)++ | src/core.c/Num.pm6
Prevent Num &infix:<cmp> from creating useless Bool

This is another commit following up on b2ae599a75. This commit replaces Num's use of &infix:<or>, which was needlessly constructing a Bool.
rakudo: 42a73f1706 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | src/core.c/Num.pm6
Merge pull request #4240 from codesections-forks/num-cmp

Add --> Order:D for Num's cmp and don't create Bools
18:43 JRaspass left
Geth rakudo: 3d2940afea | (Elizabeth Mattijsen)++ | src/core.c/Hyper.pm6
Fix one more sub reference to nodemap / deepmap

Skips one level of indirection, which is always good
lizmat hmmm... looks like camelia is stuck again, this time on 726a75e24 18:55
aka the 2021.02.1 release
18:55 linkable6 left
lizmat m: dd $*VM.version 18:56
camelia v2021.02.3.g.4.ae.157.c.33
18:56 linkable6 joined
lizmat huh? 18:56
ah, so the git commit reporting is stuck ? 18:57
Geth rakudo: b21bb5ab62 | (Elizabeth Mattijsen)++ | src/core.c/Any-iterable-methods.pm6
Make sure nodemap / deepmap pass :INITIALIZE to STORE

This indicates that it is an initialization, which is needed for Maps as these cannot be altered later.
Fixes #4237, japhb++ for the spot!
19:01 linkable6 left 19:03 linkable6 joined
Geth roast: 324d3eda72 | (Elizabeth Mattijsen)++ | S03-metaops/hyper.t
Add test for R#4237
19:08 linkable6 left 19:10 linkable6 joined 20:34 JRaspass joined 23:03 dogbert11 left 23:06 dogbert11 joined 23:08 dogbert11 left 23:16 dogbert11 joined 23:43 JRaspass left 23:52 JRaspass joined