Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

≥ and ≤ are 36x slower than Texas version; ≠ is 15x slower #6357

Open
p6rt opened this issue Jun 22, 2017 · 8 comments
Open

≥ and ≤ are 36x slower than Texas version; ≠ is 15x slower #6357

p6rt opened this issue Jun 22, 2017 · 8 comments

Comments

@p6rt
Copy link

p6rt commented Jun 22, 2017

Migrated from rt.perl.org#131626 (status was 'open')

Searchable as RT131626$

@p6rt
Copy link
Author

p6rt commented Jun 22, 2017

From @zoffixznet

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â�¤Â»

@p6rt
Copy link
Author

p6rt commented Jun 22, 2017

From @AlexDaniel

This was discussed in rakudo/rakudo#1032 (comment)

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​:

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â�¤»

@p6rt
Copy link
Author

p6rt commented Jun 22, 2017

The RT System itself - Status changed from 'new' to 'open'

@p6rt
Copy link
Author

p6rt commented Jul 10, 2017

From @zoffixznet

This bug was temporarily worked around with rakudo/rakudo@a13bad9

@p6rt
Copy link
Author

p6rt commented Sep 26, 2017

From @zoffixznet

On Mon, 10 Jul 2017 02​:42​:59 -0700, cpan@​zoffix.com wrote​:

This bug was temporarily worked around with
rakudo/rakudo@a13bad9

That was reverted in rakudo/rakudo@1af2a745fc as it causes problems.

@p6rt
Copy link
Author

p6rt commented Sep 26, 2017

From @zoffixznet

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 rakudo/rakudo@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>;
  }

@p6rt
Copy link
Author

p6rt commented Oct 22, 2017

From @zoffixznet

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 rakudo/rakudo@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​: rakudo/rakudo@6ad06fad9f

@p6rt
Copy link
Author

p6rt commented Mar 1, 2018

From @AlexDaniel

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​:

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 rakudo/rakudo@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​:
rakudo/rakudo@6ad06fad9f

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant