RFC: lower CPU usage?

[frostyplanet]

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:

1. Turn off the first one try.
2. Turn off the second try.
3. Maintain a counter for items in the channel using AtomicU64
4. Determine with mixed condition that bound size and concurrency count.
   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.

1. Add config for the channel behavior? (which seems inefficient, determining the condition will also cost CPU cycles)

2. Add a cargo feature no_eager_mode to reduce the try

[zach-schoenberger]

I think it would make sense to Turn off the first one try. since the await immediately calls the try in the future that's returned. the chance that it is not ready in the first call but ready in the second seems very low.

[frostyplanet]

The first one is because I don't know whether awaiting has a cost.
I've been digging into crossbeam-channel internal. When people talk about CPU consumption, it's all related to the backoff strategy and spin lock. There's even performance degradation after I replace RecvWakersSingle with a faster implementation. Need to do more experiments.

[zach-schoenberger]

One of the odd things i noticed about the current implementation in crossfire for was the eager try_send/recv that happens when the async function is first called, followed by the future creation that immediately calls the await. IMO the more common convention is to not have the function have the async qualifier and return the future struct without the try_* and the await. the code to use the function would still look like rx.recv().await? and it would act closer to what most users would expect. since its not common for work to be done before calling the await.

So the impl would look something like:

    pub fn recv(&self) -> ReceiveFuture<T> {
       ReceiveFuture { rx: self, waker: None }
    }

[frostyplanet]

The async fn send and recv is changed in this PR #12

[frostyplanet]

I've noticed on the comment in kanal backoff.rs, perhaps we need to consider more on spinning and yielding

pub fn spin_cond<F: Fn() -> bool>(cond: F) {
    if get_parallelism() == 1 {
        // For environments with limited resources, such as small Virtual Private
        // Servers (VPS) or single-core systems, active spinning may lead to inefficient
        // CPU usage without performance benefits. This is due to the fact that there's
        // only one thread of execution, making it impossible for another thread to make
        // progress during the spin wait period.
        while !cond() {
            yield_os();
        }
        return;
    }
...

[frostyplanet]

Auto-adjusting backoff strategy has been added in dev branch, I think the tests run faster, partially thanks to it.