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
Comments
From @zoffixznetI'd expect the fancy Unicode versions of <=, >=, and != to perform equally well, instead the Here's the timings for >= vs �: m: my $x = rand; for ^1000_000 { $ = $x >= 1_000_000_000_000 }; say now - INIT now; |
From @AlexDanielThis 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:
|
The RT System itself - Status changed from 'new' to 'open' |
From @zoffixznetThis bug was temporarily worked around with rakudo/rakudo@a13bad9 |
From @zoffixznetOn Mon, 10 Jul 2017 02:42:59 -0700, cpan@zoffix.com wrote:
That was reverted in rakudo/rakudo@1af2a745fc as it causes problems. |
From @zoffixznetOn Thu, 22 Jun 2017 10:29:59 -0700, cpan@zoffix.com wrote:
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; |
From @zoffixznetOn Tue, 26 Sep 2017 11:03:11 -0700, cpan@zoffix.com wrote:
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 Or when user defines their own version of the ASCII op: <Zoffix__> m: $ = rand � rand for ^100_000; say now - INIT now Some proposed to substitute Unicode versions for Texas ones during parsing and codegen, but the only way I It's possible we *do* want to declare that we do such aliasing: a Unicode op is just a grammatical alias For now, I basically restored lizmat++'s original fix adding whatever datish ops that were |
From @AlexDanielIt 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:
|
Migrated from rt.perl.org#131626 (status was 'open')
Searchable as RT131626$
The text was updated successfully, but these errors were encountered: