Skip to content
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

Experiment with unbounded channel types that do less allocation #8568

Closed
brson opened this issue Aug 17, 2013 · 4 comments
Closed

Experiment with unbounded channel types that do less allocation #8568

brson opened this issue Aug 17, 2013 · 4 comments
Labels
A-concurrency Area: Concurrency A-runtime Area: std's runtime and "pre-main" init for handling backtraces, unwinds, stack overflows I-slow Issue: Problems and improvements with respect to performance of generated code.

Comments

@brson
Copy link
Contributor

brson commented Aug 17, 2013

The current implementation of Chan and Port use a very simple strategy based on an atomic linked list. The implementation is alluringly simple but it requires an allocation on every send and benchmark profiles show these allocations at the top.

Let's evaluate other options.

@huonw
Copy link
Member

huonw commented Aug 18, 2013

I'd guess that (an atomic version of) extra::ringbuf would be a way to handle this.

@huonw
Copy link
Member

huonw commented Aug 30, 2013

Google turns up http://www.cs.tau.ac.il/~adamx/ppopp2013-x86queues.pdf ("Fast Concurrent Queues for x86 Processors" Morrison & Afek 2013), and that seems to suggest there aren't [m]any other array-based unbounded concurrent queues.

@brson
Copy link
Contributor Author

brson commented Oct 26, 2013

We could also experiment with the queue added in #9710. It is surely faster than the existing channels.

@alexcrichton
Copy link
Member

Closing. I've implemented an unbounded queue for Chan types which amortized doesn't perform allocations. We'd still need to do some work on SharedChan, but it's clear that avoiding allocations is a huge win here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-concurrency Area: Concurrency A-runtime Area: std's runtime and "pre-main" init for handling backtraces, unwinds, stack overflows I-slow Issue: Problems and improvements with respect to performance of generated code.
Projects
None yet
Development

No branches or pull requests

3 participants