Skip Menu |
Report information
Id: 131626
Status: open
Priority: 0/
Queue: perl6

Owner: Nobody
Requestors: cpan [at] zoffix.com
Cc:
AdminCc:

Severity: (no value)
Tag: testneeded
Platform: (no value)
Patch Status: (no value)
VM: (no value)



Subject: [PERF] ≥ and ≤ are 36x slower than Texas version; ≠ is 15x slower
Download (untitled) / with headers
text/plain 668b
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␤»
This was discussed in https://github.com/rakudo/rakudo/pull/1032#issuecomment-284217342

In theory, this ticket should apply for other ops as well.

Note that I said that I will change the way unicode ops are implemented, but I didn't have much time since then. Hoping to get to it at some point.

On 2017-06-22 10:29:59, cpan@zoffix.com wrote:
Show quoted text
> 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␤»


Download (untitled) / with headers
text/plain 284b
On Mon, 10 Jul 2017 02:42:59 -0700, cpan@zoffix.com wrote: Show quoted text
That was reverted in https://github.com/rakudo/rakudo/commit/1af2a745fc as it causes problems.
RT-Send-CC: perl6-compiler [...] perl.org
Download (untitled) / with headers
text/plain 1.4k
On Thu, 22 Jun 2017 10:29:59 -0700, cpan@zoffix.com wrote: Show quoted text
> 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>; }
RT-Send-CC: perl6-compiler [...] perl.org
Download (untitled) / with headers
text/plain 2.9k
On Tue, 26 Sep 2017 11:03:11 -0700, cpan@zoffix.com wrote: Show quoted text
> On Thu, 22 Jun 2017 10:29:59 -0700, cpan@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


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org