[perl #131626] [PERFTEST][PERF] ≥ and ≤ are 36x slower than Texas version; ≠ is 15x slower

[Zoffix Znet via RT]

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