|
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 |
03:29 | |
|
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: stackoverflow.com/questions/664966...es-sorting 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) |
11:25 | |
| 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. |
12:48 | |
| 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 | |||
| 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 | ||
| true | |||
| 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) |
13:42 | |
| 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:06 | |
|
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:38 | |
|
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:51 | |
|
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 |
15:19 | |
| 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 |
16:40 | |
| 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. |
17:43 | |
| 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 |
18:44 | |
| 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:00 | |
|
19:01
linkable6 left
19:03
linkable6 joined
|
|||
| Geth | roast: 324d3eda72 | (Elizabeth Mattijsen)++ | S03-metaops/hyper.t Add test for R#4237 |
19:07 | |
|
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
|
|||