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
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, cpan@zoffix.com wrote:
Show quoted text
> On Tue, 26 Sep 2017 11:03:11 -0700, cpan@zoffix.com wrote:
> > 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