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

.grep-ing Ints with a code block is now almost twice slower ( .grep({/foo/}) ) #6414

Open
p6rt opened this issue Jul 27, 2017 · 5 comments
Open
Labels
perf regression Issue did not exist previously

Comments

@p6rt
Copy link

p6rt commented Jul 27, 2017

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

Searchable as RT131805$

@p6rt
Copy link
Author

p6rt commented Jul 27, 2017

From @AlexDaniel

See this benchable6 output​: https://gist.github.com/Whateverable/6001c5744e3c877d76928d465de31e46

If you look closely, benchable has not only built the graph across all releases, but it also bisected the performance drop to the exact commit. Here is that commit​: rakudo/rakudo@b7201a8

This was double-checked with committable6​:
<AlexDaniel> c​: b7201a8^,b7201a8 (^99999).grep({!/1/}).elems.say; say now - BEGIN now
<committable6> AlexDaniel, ¦b7201a8^​: «59048␤5.0481256» ¦b7201a8​: «59048␤9.0262629»

So it is ≈5 seconds before vs ≈9 seconds after. A significant performance drop even if we assume possible bench noise.

This was noticed because of this ticket​: Raku/doc#1425

See also IRC discussion​: https://irclog.perlgeek.de/perl6/2017-07-27#i_14927626

And maybe coverable output on HEAD if it may help you​: https://gist.github.com/Whateverable/f3db9e924cebe9b96a71a2b4cd67ae9c

Note that whether it's {!/1/} or {/1/} doesn't really matter​: https://irclog.perlgeek.de/perl6/2017-07-27#i_14927789

@p6rt
Copy link
Author

p6rt commented Jul 27, 2017

From @lizmat

Looking at the profile of

  (^10000).grep({!/1/}).elems.say

the first 5 entries (responsible for 70% of CPU in that example) have nothing to do with matching, but everything with trying to find the right dispatchee. And it looks like this is basically caused by​:

  $_ = 1; /1/

Because $_ contains an Int, this becomes a very slow path. Compare this with​:

  (^10000)>>.Str.grep({!/1/}).elems.say

which is 3x faster, even when using a sub-optimal hyper.

Investigating further...

On 27 Jul 2017, at 04​:06, Aleks-Daniel Jakimenko-Aleksejev (via RT) <perl6-bugs-followup@​perl.org> wrote​:

# New Ticket Created by Aleks-Daniel Jakimenko-Aleksejev
# Please include the string​: [perl #​131805]
# in the subject line of all future correspondence about this issue.
# <URL​: https://rt-archive.perl.org/perl6/Ticket/Display.html?id=131805 >

See this benchable6 output​: https://gist.github.com/Whateverable/6001c5744e3c877d76928d465de31e46

If you look closely, benchable has not only built the graph across all releases, but it also bisected the performance drop to the exact commit. Here is that commit​: rakudo/rakudo@b7201a8

This was double-checked with committable6​:
<AlexDaniel> c​: b7201a8^,b7201a8 (^99999).grep({!/1/}).elems.say; say now - BEGIN now
<committable6> AlexDaniel, ¦b7201a8^​: «59048␤5.0481256» ¦b7201a8​: «59048␤9.0262629»

So it is ≈5 seconds before vs ≈9 seconds after. A significant performance drop even if we assume possible bench noise.

This was noticed because of this ticket​: Raku/doc#1425

See also IRC discussion​: https://irclog.perlgeek.de/perl6/2017-07-27#i_14927626

And maybe coverable output on HEAD if it may help you​: https://gist.github.com/Whateverable/f3db9e924cebe9b96a71a2b4cd67ae9c

Note that whether it's {!/1/} or {/1/} doesn't really matter​: https://irclog.perlgeek.de/perl6/2017-07-27#i_14927789

@p6rt
Copy link
Author

p6rt commented Jul 27, 2017

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

@p6rt
Copy link
Author

p6rt commented Jul 27, 2017

From @AlexDaniel

Oh! You're totally right!

Then, it's not as bad as it looks.

In fact, this commit actually *improved* the case when it has to match Str-s (more than 2x speedup).

So perhaps the slowdown is not so critical. After all, how often do people match thousands of Ints…

On 2017-07-26 23​:55​:21, elizabeth wrote​:

Looking at the profile of

(^10000).grep({!/1/}).elems.say

the first 5 entries (responsible for 70% of CPU in that example) have
nothing to do with matching, but everything with trying to find the
right dispatchee. And it looks like this is basically caused by​:

$_ = 1; /1/

Because $_ contains an Int, this becomes a very slow path. Compare
this with​:

(^10000)>>.Str.grep({!/1/}).elems.say

which is 3x faster, even when using a sub-optimal hyper.

Investigating further...

On 27 Jul 2017, at 04​:06, Aleks-Daniel Jakimenko-Aleksejev (via RT)
<perl6-bugs-followup@​perl.org> wrote​:

# New Ticket Created by Aleks-Daniel Jakimenko-Aleksejev
# Please include the string​: [perl #​131805]
# in the subject line of all future correspondence about this issue.
# <URL​: https://rt-archive.perl.org/perl6/Ticket/Display.html?id=131805 >

See this benchable6 output​:
https://gist.github.com/Whateverable/6001c5744e3c877d76928d465de31e46

If you look closely, benchable has not only built the graph across
all releases, but it also bisected the performance drop to the exact
commit. Here is that commit​:
rakudo/rakudo@b7201a8

This was double-checked with committable6​:
<AlexDaniel> c​: b7201a8^,b7201a8 (^99999).grep({!/1/}).elems.say; say
now - BEGIN now
<committable6> AlexDaniel, ¦b7201a8^​: «59048␤5.0481256» ¦b7201a8​:
«59048␤9.0262629»

So it is ≈5 seconds before vs ≈9 seconds after. A significant
performance drop even if we assume possible bench noise.

This was noticed because of this ticket​:
Raku/doc#1425

See also IRC discussion​: https://irclog.perlgeek.de/perl6/2017-07-
27#i_14927626

And maybe coverable output on HEAD if it may help you​:
https://gist.github.com/Whateverable/f3db9e924cebe9b96a71a2b4cd67ae9c

Note that whether it's {!/1/} or {/1/} doesn't really matter​:
https://irclog.perlgeek.de/perl6/2017-07-27#i_14927789

@p6rt
Copy link
Author

p6rt commented Jul 27, 2017

From @lizmat

It’s really in the dispatch within Cool. Note the difference between​:

  for ^10000 { 1.match(/1/) }

and​:

  for ^10000 { "1".match(/1/) }

I’m afraid this is really uncovering a basic dispatch caching issue.

I have tried a few things, but I’m afraid this is really an issue inside “find_best_dispatchee” in the bootstrap

On 27 Jul 2017, at 09​:37, Aleks-Daniel Jakimenko-Aleksejev via RT <perl6-bugs-followup@​perl.org> wrote​:

Oh! You're totally right!

Then, it's not as bad as it looks.

In fact, this commit actually *improved* the case when it has to match Str-s
(more than 2x speedup).

So perhaps the slowdown is not so critical. After all, how often do people
match thousands of Ints…

On 2017-07-26 23​:55​:21, elizabeth wrote​:

Looking at the profile of

(^10000).grep({!/1/}).elems.say

the first 5 entries (responsible for 70% of CPU in that example) have
nothing to do with matching, but everything with trying to find the
right dispatchee. And it looks like this is basically caused by​:

$_ = 1; /1/

Because $_ contains an Int, this becomes a very slow path. Compare
this with​:

(^10000)>>.Str.grep({!/1/}).elems.say

which is 3x faster, even when using a sub-optimal hyper.

Investigating further...

On 27 Jul 2017, at 04​:06, Aleks-Daniel Jakimenko-Aleksejev (via RT)
<perl6-bugs-followup@​perl.org> wrote​:

# New Ticket Created by Aleks-Daniel Jakimenko-Aleksejev
# Please include the string​: [perl #​131805]
# in the subject line of all future correspondence about this issue.
# <URL​: https://rt-archive.perl.org/perl6/Ticket/Display.html?id=131805 >

See this benchable6 output​:
https://gist.github.com/Whateverable/6001c5744e3c877d76928d465de31e46

If you look closely, benchable has not only built the graph across
all releases, but it also bisected the performance drop to the exact
commit. Here is that commit​:

rakudo/rakudo@b7201a8

This was double-checked with committable6​:
<AlexDaniel> c​: b7201a8^,b7201a8 (^99999).grep({!/1/}).elems.say; say
now - BEGIN now
<committable6> AlexDaniel, ¦b7201a8^​: «59048␤5.0481256» ¦b7201a8​:
«59048␤9.0262629»

So it is ≈5 seconds before vs ≈9 seconds after. A significant
performance drop even if we assume possible bench noise.

This was noticed because of this ticket​:
Raku/doc#1425

See also IRC discussion​: https://irclog.perlgeek.de/perl6/2017-07-
27#i_14927626

And maybe coverable output on HEAD if it may help you​:
https://gist.github.com/Whateverable/f3db9e924cebe9b96a71a2b4cd67ae9c

Note that whether it's {!/1/} or {/1/} doesn't really matter​:
https://irclog.perlgeek.de/perl6/2017-07-27#i_14927789

@p6rt p6rt added perf regression Issue did not exist previously labels Jan 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
perf regression Issue did not exist previously
Projects
None yet
Development

No branches or pull requests

1 participant