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

Simplify AtomicBool::fetch_nand #40563

Closed
wants to merge 2 commits into from

Conversation

mstewartgallus
Copy link
Contributor

This should also be faster.

This code avoids storing in cases where there would not be a change.

This should also be faster
@rust-highfive
Copy link
Collaborator

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @aturon (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

@alexcrichton
Copy link
Member

Looks like tests are failing?

@nagisa
Copy link
Member

nagisa commented Mar 16, 2017

I think you can simply self.swap(true, order) if val is false.

@mstewartgallus
Copy link
Contributor Author

@nagis That is true. However, a swap implies a write all the time instead while a compare and swap does not which can be faster sometimes. In any case the bug was in the if val part so I replaced that with a fetch_xor. The commit will be up in a bit.

@alexcrichton
Copy link
Member

The lack of a loop around the false branch here looks very worrisome to me, is there a reason why there's no loop around that?

@mstewartgallus
Copy link
Contributor Author

@alexcrichton That's deliberate. !(x && false) = true. If x is true and not false then no write needs to happen which is good for the cache.

// !(false && true) == true

// !(x && true) == !x
// !(x && false) == true
Copy link
Member

Choose a reason for hiding this comment

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

I would use & instead of && in these, seems clearer.

// !(x && true) == !x
// !(x && false) == true
if val {
return self.fetch_xor(true, order);
Copy link
Member

Choose a reason for hiding this comment

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

Explicit return isn't needed.

@mstewartgallus
Copy link
Contributor Author

This is odd https://travis-ci.org/rust-lang/rust/jobs/213176849 I can't view what happened here.

@nagisa
Copy link
Member

nagisa commented Mar 21, 2017 via email

@eddyb
Copy link
Member

eddyb commented Mar 21, 2017

@sstewartgallus Only one configuration is supposed to run on a PR, but the only way to do that in travis is to finish immediately for non-PR configurations. But macOS ones sometimes even fail at that.
I've restarted it for you, should show green in a couple minutes.

@alexcrichton
Copy link
Member

Do you have benchmarks for this as well to justify this change?

@alexcrichton alexcrichton added the T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. label Mar 21, 2017
@mstewartgallus
Copy link
Contributor Author

@alexcrichton Fair enough. However, as this is in libcore I can't easily use std::threads for benchmarking purposes can I?

@eddyb
Copy link
Member

eddyb commented Mar 21, 2017

@sstewartgallus You can write your own standalone benchmark.

@ghost
Copy link

ghost commented Apr 6, 2017

Benchmark: source
Results:

test new_ce_1t   ... bench:      89,904 ns/iter (+/- 7,130)
test new_ce_2t   ... bench:     316,835 ns/iter (+/- 367,981)
test new_ce_4t   ... bench:   1,005,424 ns/iter (+/- 320,508)
test new_swap_1t ... bench:      90,034 ns/iter (+/- 12,027)
test new_swap_2t ... bench:     315,171 ns/iter (+/- 297,658)
test new_swap_4t ... bench:   1,000,136 ns/iter (+/- 139,235)
test old_1t      ... bench:     146,440 ns/iter (+/- 20,576)
test old_2t      ... bench:     561,456 ns/iter (+/- 715,659)
test old_4t      ... bench:   2,822,821 ns/iter (+/- 1,544,049)

Pretty good imprevements! :)

Let's just get rid of that unnecessary return and add a test for fetch_nand to src/libcore/tests/atomic.rs.

@ghost ghost mentioned this pull request Apr 7, 2017
@ghost
Copy link

ghost commented Apr 7, 2017

Let's close this stale PR, as we've pushed the changes forward through a newer PR.
I'd like to thank @sstewartgallus - this is an excellent performance improvement! :)

@eddyb eddyb closed this Apr 7, 2017
frewsxcv added a commit to frewsxcv/rust that referenced this pull request Apr 7, 2017
…r=nagisa

Optimize AtomicBool::fetch_nand

This is an attempt to push the PR rust-lang#40563 to completion.

Benchmark: [source](https://gist.github.com/stjepang/023f5025623f5474184f9f4dfd6379ae)
Improvement:

```
 name  old_ ns/iter  new_ce_ ns/iter  diff ns/iter   diff %
 1t    146,440       89,904                -56,536  -38.61%
 2t    561,456       316,835              -244,621  -43.57%
 4t    2,822,821     1,005,424          -1,817,397  -64.38%
```

r? @eddyb
cc @alexcrichton @nagisa
TimNN added a commit to TimNN/rust that referenced this pull request Apr 8, 2017
…r=nagisa

Optimize AtomicBool::fetch_nand

This is an attempt to push the PR rust-lang#40563 to completion.

Benchmark: [source](https://gist.github.com/stjepang/023f5025623f5474184f9f4dfd6379ae)
Improvement:

```
 name  old_ ns/iter  new_ce_ ns/iter  diff ns/iter   diff %
 1t    146,440       89,904                -56,536  -38.61%
 2t    561,456       316,835              -244,621  -43.57%
 4t    2,822,821     1,005,424          -1,817,397  -64.38%
```

r? @eddyb
cc @alexcrichton @nagisa
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants