Performance improvement: prevent false sharing #9
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
Prevents false sharing when one thread writes to key_gen_ and others read other class members (that reside on the same cache line)
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 PR prevents false sharing between writing to
key_gen_and reading any of the index members (as well as invoking virtual methods).I noticed a performance hit in rubis benchmark with many threads. I saw a very long
time_commitvalue (when enabled the performance measurements). Perf pointed me to reading the virtual table ofordered_index. The reason was that some transactions were in the process of committing (and invoking virtual methods ofordered_index), while other transactions were incrementing thekey_gen_member.The best solution would be to also prevent writing to the same memory location by many threads as it causes contention, but this PR improves current things with minimal changes.
I noticed a huge improvement (in the order of 2x) when running rubis with 64 threads after this change