Optimized Skiplist
with unboxed Atomic_array
#138
Draft
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.
For background, see PR in multicore-magic.
This seems to give up to 40%-70% performance improvement in some cases and seems to generally improve performance. The reason for the speed up is obvious: 3x less words per a link in a node and 1 less indirection. This means things will better fit into caches and there will be less stalls waiting for memory.
It is interesting to note that despite having only a
fenceless_get
and not having an "atomic"get
, this seems to pass the QCheck STM test. I assume this is due to the use of the linearizable size. All add and remove operations update the linearizable size, which means they will be linearizable. Read-only operations also potentially update the linearizable size. It seems that is enough to keep the data structure linearizable even when reads from the atomic arrays are relaxed reads rather than sequentially consistent reads.TODO:
Atomic_array
— this happened automatically after the switch to usemulticore-magic-dscheck