RFC: lower CPU usage? #9
Unanswered
frostyplanet
asked this question in
Ideas
Replies: 2 comments 4 replies
-
|
I think it would make sense to |
Beta Was this translation helpful? Give feedback.
3 replies
-
|
I've noticed on the comment in kanal backoff.rs, perhaps we need to consider more on spinning and yielding |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Currently, in AsyncRx (the same case with AsyncTx), async fn recv will try_recv 3 times. One before ReceiveFuture, two in poll_item.
The good side of lockless implementation is that it increases throughput when channel bound is sufficient and Sender & Receiver in enough, but at the cost of CPU usage. The bad side is that in size=1 case, when contention is high, lockless channel costs a lot of CPU in trying without success, not as efficient as Flume.
I have done some experiments:
All turned out to hurt the MPSC / MPMC benchmarks a lot; sometimes, bounded size 1 tests were better, but not stable to reproduce.
I'm also notice some people complain about crossbeam's CPU usage crossbeam-rs/crossbeam#821
I don't know whether people think the CPU consumption is an issue. Is it necessary to save some CPU cycles for other purposes?
I am out of job at the moment and don't have the environment to do real-world experiment. So I‘m asking for options.
Add config for the channel behavior? (which seems inefficient, determining the condition will also cost CPU cycles)
Add a cargo feature
no_eager_modeto reduce the tryBeta Was this translation helpful? Give feedback.
All reactions