Skip to content

Conversation

@cuviper
Copy link
Member

@cuviper cuviper commented Apr 12, 2017

No description provided.

cuviper added 3 commits April 11, 2017 22:59
Since `sum` and `product` became their own things, `reduce` doesn't need
the `ReduceOp` abstraction any more.
We can use a simpler match with `fold` in implementing `reduce_with`,
before passing to the more complicated match where both sides are
options.  This may help the compiler optimize better.
These call a user's function to compare values, just like the methods
added to `Iterator` in Rust 1.15.0.
(Some(v), None) | (None, Some(v)) => Some(v),
(None, None) => None,
})
self.fold(|| None, |opt_a, b| match opt_a {
Copy link
Member

Choose a reason for hiding this comment

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

Why change this?

Copy link
Member Author

Choose a reason for hiding this comment

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

It seems like a waste to wrap values in Some only to immediately match that away. It requires inlining and optimization to realize that the right side always has something while folding. In practice, I couldn't measure a difference, so I'll drop this change if you prefer.

Copy link
Member

Choose a reason for hiding this comment

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

I see. That's true. I don't have a strong opinion, just curious. I agree that it seems like this formulation might unlock some optimization somehow.

@nikomatsakis nikomatsakis merged commit 65cb5af into rayon-rs:master Apr 12, 2017
@cuviper cuviper deleted the reductions branch April 15, 2017 22:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants