Pin threads to a cores #365
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
Signed-off-by: Stefan Marr <git@stefan-marr.de>
Signed-off-by: Stefan Marr <git@stefan-marr.de>
If available, each thread should get their own core. This isn’t conditional or sophisticated, but should help for single core benchmarking to reduce noise. - to make this work, we need to communicate the available cores for pinning. Thus, determine core mask based on REBENCH_DENOISE_CORE_SET env var. - also introduce a flag to disable pinning altogether Signed-off-by: Stefan Marr <git@stefan-marr.de>
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.
This is hopefully a good idea in general.
We have fork/join pools sized so that each thread corresponds to a physical core, and we don't necessarily need them to wander around.
However, for instance actors are scheduled still on the fork/join pool and not bound to a thread.
So, they may still wander about.
Though, the benchmarks are not necessarily faster, just more predictable.
@daumayr this may have an impact for you in the future, and we may need to see whether this causes any regressions.
@sophie-kaleba I would recommend that we add this to the other SOMs as well, especially grSOM and TruffleSOM.
This makes quite a bit of difference in the amount of noise that benchmarks measure, I think.
Still need to do a proper analysis and write up, but I think it should make benchmarking more reliable.
Note
This doesn't support the native image variant at the moment. For native-image support, it's likely easier to use the underlying system API directly.