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

Add iterator method specialisations to Range* #47180

Merged
merged 9 commits into from
Jan 11, 2018

Conversation

varkor
Copy link
Member

@varkor varkor commented Jan 4, 2018

Add specialised implementations of max for Range, and last, min and max for RangeInclusive, all of which lead to significant advantages in the generated assembly on x86.

Note that adding specialisations of min and last for Range led to no benefit, and adding sum for Range and RangeInclusive led to type inference issues (though this is possibly still worthwhile considering the performance gain).

This addresses some of the concerns in #39975.

@rust-highfive
Copy link
Collaborator

r? @withoutboats

(rust_highfive has picked a reviewer for you, use r? to override)


#[inline]
fn min(self) -> Option<A> {
Some(self.start)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Currently min for RangeFrom will either panic with overflow or loop forever so this is a change of behaviour. As RangeFrom is fundamentally broken right now (#25708) I don't think it's a good idea to specialise methods for it just yet.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I was considering not adding this yet. I'll remove it, as it would be better placed in a separate change.

@alexcrichton alexcrichton added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jan 4, 2018
@withoutboats
Copy link
Contributor

@bors r? @alexcrichton


#[inline]
fn max(self) -> Option<A> {
Some(self.end)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't this and last return None once the iterator is exhausted?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, it definitely should.

@bluss
Copy link
Member

bluss commented Jan 5, 2018

You can use either self.next() or self.next_back() in all of these to get the right Some/Noneness

@alexcrichton
Copy link
Member

Thanks! Although now that it's been brought up, @bluss's suggestion sounds like a great way to future-proof these as well. Want to implement it via that?

@alexcrichton
Copy link
Member

@bors: r+

Nice!

@bors
Copy link
Contributor

bors commented Jan 8, 2018

📌 Commit 2d83343 has been approved by alexcrichton

@varkor
Copy link
Member Author

varkor commented Jan 8, 2018

I've been doing some benchmarks, and I must have overlooked something before, because min for Range does lead to performance gains, although last does seem not to. It might be worth implementing them both for consistency, though. I'm going to push another commit adding them — sorry for the confusion!

Something odd is going on with optimisation for min — I'll look into it, but it's easier to leave it for a follow-up commit.

@bors
Copy link
Contributor

bors commented Jan 8, 2018

⌛ Testing commit 2d83343 with merge c209f57...

bors added a commit that referenced this pull request Jan 8, 2018
Add iterator method specialisations to Range*

Add specialised implementations of `max` for `Range`, and `last`, `min` and `max` for `RangeInclusive`, all of which lead to significant advantages in the generated assembly on x86.

Note that adding specialisations of `min` and `last` for `Range` led to no benefit, and adding `sum` for `Range` and `RangeInclusive` led to type inference issues (though this is possibly still worthwhile considering the performance gain).

This addresses some of the concerns in #39975.
@bors
Copy link
Contributor

bors commented Jan 8, 2018

💔 Test failed - status-appveyor

@alexcrichton
Copy link
Member

@bors
Copy link
Contributor

bors commented Jan 8, 2018

⌛ Testing commit 2d83343 with merge 2248d5b...

bors added a commit that referenced this pull request Jan 8, 2018
Add iterator method specialisations to Range*

Add specialised implementations of `max` for `Range`, and `last`, `min` and `max` for `RangeInclusive`, all of which lead to significant advantages in the generated assembly on x86.

Note that adding specialisations of `min` and `last` for `Range` led to no benefit, and adding `sum` for `Range` and `RangeInclusive` led to type inference issues (though this is possibly still worthwhile considering the performance gain).

This addresses some of the concerns in #39975.
@bors
Copy link
Contributor

bors commented Jan 9, 2018

💔 Test failed - status-appveyor

@alexcrichton
Copy link
Member

alexcrichton commented Jan 9, 2018

@bors
Copy link
Contributor

bors commented Jan 9, 2018

⌛ Testing commit 2d83343 with merge f67c277525fa3fd4fad5624b058b411ee495e1ff...

@bors
Copy link
Contributor

bors commented Jan 9, 2018

💔 Test failed - status-appveyor

@kennytm
Copy link
Member

kennytm commented Jan 9, 2018

@bors r-

I think 3 consecutive timeouts indicate there's some performance problem here (or you are really unlucky). @varkor could you investigate the "min" optimization mentioned #47180 (comment)?

(We could re-r+ if it turns out there's nothing more to do)

@kennytm kennytm added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jan 9, 2018
@varkor
Copy link
Member Author

varkor commented Jan 9, 2018

The min method is now taking ~1 n/s to execute, on par with the other methods. I can't see this being the issue though, because each of the changes in the previous commit only improved the efficiency of the iterator methods. I don't see how any of these changes could be a regression.

@kennytm kennytm added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jan 9, 2018
@alexcrichton
Copy link
Member

@bors: r+

@bors
Copy link
Contributor

bors commented Jan 10, 2018

📌 Commit 919d643 has been approved by alexcrichton

@bors
Copy link
Contributor

bors commented Jan 10, 2018

⌛ Testing commit 919d643 with merge 9959d8a...

bors added a commit that referenced this pull request Jan 10, 2018
Add iterator method specialisations to Range*

Add specialised implementations of `max` for `Range`, and `last`, `min` and `max` for `RangeInclusive`, all of which lead to significant advantages in the generated assembly on x86.

Note that adding specialisations of `min` and `last` for `Range` led to no benefit, and adding `sum` for `Range` and `RangeInclusive` led to type inference issues (though this is possibly still worthwhile considering the performance gain).

This addresses some of the concerns in #39975.
@bors
Copy link
Contributor

bors commented Jan 10, 2018

💔 Test failed - status-appveyor

@kennytm
Copy link
Member

kennytm commented Jan 11, 2018

@bors retry

@bors
Copy link
Contributor

bors commented Jan 11, 2018

⌛ Testing commit 919d643 with merge 73ac5d6...

bors added a commit that referenced this pull request Jan 11, 2018
Add iterator method specialisations to Range*

Add specialised implementations of `max` for `Range`, and `last`, `min` and `max` for `RangeInclusive`, all of which lead to significant advantages in the generated assembly on x86.

Note that adding specialisations of `min` and `last` for `Range` led to no benefit, and adding `sum` for `Range` and `RangeInclusive` led to type inference issues (though this is possibly still worthwhile considering the performance gain).

This addresses some of the concerns in #39975.
@bors
Copy link
Contributor

bors commented Jan 11, 2018

☀️ Test successful - status-appveyor, status-travis
Approved by: alexcrichton
Pushing 73ac5d6 to master...

@bors bors merged commit 919d643 into rust-lang:master Jan 11, 2018
varkor added a commit to varkor/rust that referenced this pull request Jan 11, 2018
Calling `min` on `RangeFrom` currently causes an infinite loop.
Although other methods such as `max` also result in an infinite loop,
it is strictly incorrect in the case of `min`. Adding a specialisation
fixes this.

Separated from rust-lang#47180 because
this technically changes behaviour; it’s not just an optimisation, so
it’s a little different.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-review Status: Awaiting review from the assignee but also interested parties.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants