Agree, should be closed.
> On 1 Mar 2018, at 15:10, Aleks-Daniel Jakimenko-Aleksejev via RT > <perl6-bugs-follo...@perl.org> wrote: > > It seems like it is fixed properly now. See this discussion: > https://irclog.perlgeek.de/perl6-dev/2018-03-01#i_15872426 > > On 2017-10-22 08:28:20, c...@zoffix.com wrote: >> On Tue, 26 Sep 2017 11:03:11 -0700, c...@zoffix.com wrote: >>> On Thu, 22 Jun 2017 10:29:59 -0700, c...@zoffix.com wrote: >>>> I'd expect the fancy Unicode versions of <=, >=, and != to perform >>>> equally well, instead the >>>> ≥ and ≤ are 36x slower than their Texas companions and ≠ is 15x >>>> slower. >>>> >>>> Here's the timings for >= vs ≥: >>>> >>>> m: my $x = rand; for ^1000_000 { $ = $x >= 1_000_000_000_000 }; say >>>> now - INIT now; >>>> rakudo-moar 43c176: OUTPUT: «0.74663187» >>>> m: my $x = rand; for ^1000_000 { $ = $x ≥ 1_000_000_000_000 }; say >>>> now >>>> - INIT now; >>>> rakudo-moar 43c176: OUTPUT: «(timeout)» >>>> m: my $x = rand; for ^1000_0 { $ = $x ≥ 1_000_000_000_000 }; say >>>> now >>>> - >>>> INIT now; >>>> rakudo-moar 43c176: OUTPUT: «0.2661272» >>>> m: say 0.2661272*100 / 0.729002 >>>> rakudo-moar 43c176: OUTPUT: «36.505689» >>> >>> >>> So I made the static optimizer change Mexico ops to Texas versions, >>> so >>> this problem no longer exist. So, should the ticket be closed? >>> >>> Fixed in https://github.com/rakudo/rakudo/commit/6ec21cb473 >>> >>> I tried writing a test, but couldn't get anything usable. My attempt >>> was this: >>> >>> use Test; >>> subtest 'performance of ≤, ≥, ≠ compared to Texas versions' => { >>> sub measure (&code) { code for ^300; with now { code for >>> ^100_000; >>> now - $_ } } >>> >>> is-approx { rand ≤ rand }.&measure, { rand <= rand }.&measure, '≤', >>> :rel-tol<.5>; >>> is-approx { rand ≥ rand }.&measure, { rand >= rand }.&measure, '≥', >>> :rel-tol<.5>; >>> is-approx { rand ≠ rand }.&measure, { rand != rand }.&measure, '≠', >>> :rel-tol<.5>; >>> } >> >> >> So the optimizer fix didn't do a full job. There were still cases that >> ended up 86x slower: >> >> When chained: >> >> <Zoffix__> m: $ = rand ≤ rand ≤ rand for ^100_000; say now - INIT now >> <camelia> rakudo-moar a042fd927: OUTPUT: «2.91023964» >> <Zoffix__> m: $ = rand <= rand <= rand for ^100_000; say now - INIT >> now >> <camelia> rakudo-moar a042fd927: OUTPUT: «0.094577» >> >> Or when user defines their own version of the ASCII op: >> >> <Zoffix__> m: $ = rand ≤ rand for ^100_000; say now - INIT now >> <camelia> rakudo-moar a042fd927: OUTPUT: «0.0474443» >> <Zoffix__> m: class Foo {}; sub infix:«<=» (Foo, Foo) {}; $ = rand ≤ >> rand for ^100_000; say now - INIT now >> <camelia> rakudo-moar a042fd927: OUTPUT: «1.94282032» >> >> Some proposed to substitute Unicode versions for Texas ones during >> parsing and codegen, but the only way I >> know how to do that would make user's use of `≠` use a custom `!=` op, >> if one exists. >> >> It's possible we *do* want to declare that we do such aliasing: a >> Unicode op is just a grammatical alias >> to the ASCII op and gets rewritten to it. If there's a consensus to do >> that, it should be done for all the ops, >> even ones that don't have this performance issue (which is due to >> capture slipping). >> >> For now, I basically restored lizmat++'s original fix adding whatever >> datish ops that were >> originally missing as well: >> https://github.com/rakudo/rakudo/commit/6ad06fad9f
