add demo to simulate usage in a game engine #603
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
At RustConf we were discussing the general idea that we may be too aggressive about waking threads, and too slow about putting them back to sleep. I worried about this as a broad problem as core & thread counts rise, when there won't always be enough work to spread around. So, this is great to have a real demo of the issue! |
|
Ah, we were discussing wake-ups in the cross-linked issue #576 too. |
cuviper
requested changes
Oct 9, 2018
There was a problem hiding this comment.
Please use platform specific dependencies for libc and winapi, with appropriate cfg on their extern crate declarations too.
Otherwise, looks good to me!
cuviper
approved these changes
Oct 11, 2018
|
bors r+ |
bors bot
added a commit
that referenced
this pull request
Oct 11, 2018
603: add demo to simulate usage in a game engine r=cuviper a=mdonoughe It has been observed in amethyst/amethyst#780 that if you use Rayon in an environment where you are not CPU bound, you may end up using many more CPU cycles than necessary. This pull request adds an example of this problem to the demo project as a starting point towards finding a way to improve efficiency in this scenario. The life demo now has a `play` mode where the same comparison of serial and parallel occurs, but with a frame (generation) per second limit in place and comparing CPU time measurements at the end. Example output for my Ryzen 7 1800X with hyperthreading (16 logical processors) in Windows 10: $ rayon-demo life play serial: 59.93 fps cpu usage: 4.7% parallel: 59.97 fps cpu usage: 55.3% par_bridge: 59.94 fps cpu usage: 1164.1% Once there are ways to improve the overhead they should be incorporated into this demo as an example. If there are already ways to improve the demo let me know and I can try to implement them now. Co-authored-by: Matthew Donoughe <mdonoughe@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
It has been observed in amethyst/amethyst#780 that if you use Rayon in an environment where you are not CPU bound, you may end up using many more CPU cycles than necessary. This pull request adds an example of this problem to the demo project as a starting point towards finding a way to improve efficiency in this scenario.
The life demo now has a
playmode where the same comparison of serial and parallel occurs, but with a frame (generation) per second limit in place and comparing CPU time measurements at the end.Example output for my Ryzen 7 1800X with hyperthreading (16 logical processors) in Windows 10:
Once there are ways to improve the overhead they should be incorporated into this demo as an example. If there are already ways to improve the demo let me know and I can try to implement them now.