-
Notifications
You must be signed in to change notification settings - Fork 472
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
Introduce crossbeam-circbuf #277
base: master
Are you sure you want to change the base?
Conversation
It seems CI fails due to unrelated issue: https://travis-ci.org/crossbeam-rs/crossbeam/jobs/472150001#L455 bors retry |
By extending the
And here is MPMC queue:
By bumping the block size from 32 to 256 we get even better results:
And this is
My takeaways are:
I should also add that it's possible that these benchmarks are not measuring the right thing and might be unfair to |
Do you have any numbers or perhaps benchmarks I could run to reproduce them? In my first comment on this PR, I noted it takes 0.123 sec for the bounded SPSC variant of The new bounded SPSC queue spends 0.029 sec on that same benchmark, which is 6 ns per message. That's 4x faster than I honestly doubt the double indirection costs much, if anything (my guess is less than 1 ns per message). The new bounded SPSC queue uses double indirection too, so it definitely cannot cost more than 6 ns per message. Even if we conservatively assume the cost of double indirection is the whole 6 ns per message, that would mean removing it brings the result for |
@stjepang I prepared for the DST branch a long time ago, so maybe I'm wrong to attribute performance difference to pointer indirection. There may be orthogonal improvements I forgot about. I'll soon provide benchmark setup and numbers. Sorry for the delay. |
f6e30f5
to
cc18736
Compare
I'm proposing to introduce
crossbeam-circbuf
, which implements bounded/unbounded SPSC/SPMC queues based on circular buffer. Bounded queues are implemented with fixed-sized circular buffer. Unbounded queues are implemented with dynamically growable/shrinkable circular buffer.Currently I'm not sure how performant this crate is. A few benchmark will be helpful in evaluating the performance. I'm thinking of re-purposing the benchmark used in
crossbeam-channel
.The implementation is sub-optimal in that it has an unnecessary indirection when accessing the underlying buffer. In order to remove the indireciton we need to support DST, which is not yet implemented in Crossbeam, though.
We discussed to introduce
crossbeam-circbuf
in another PR, and there we also discussed tentative crate organizations. Speaking of organizations, I thinkcrossbeam-deque
andcrossbeam-arrayqueue
can also be incorporated in this crate for the following reasons:All of them share the same buffer struct.
crossbeam-arrayqueue
is actually bounded MPMC queue based on circular buffer.crossbeam-deque
is actually a slight variant of unbounded SPMC queue based on circular buffer.