If I'm not mistaken,

seems to assume RISC-V uses 32-byte lines. RISC-V didn't originally define the line size, but recent extension Zic64b defines the line as 64-bytes and this is empirically observed to be the common choice for RV64 implementations (same for Aarch64 I'd assume, but haven't checked).

An alignment of 32-bytes will hurt performance on a 64-byte line implementation, where the reverse will [just] waste memory.

I did some timing measurements on your benchmarks (for non-blocking SPSC) and I found that only a small part of them measure the multi-threaded behavior of the queue.

Here are some timings that I measured:

The benchmarks include the time for the creation and initialization of the queue, but that's not a big deal, since that's less than 2 usec.

More importantly, it also measures the creation of the thread, which means that the main thread starts reading from the queue only after about 30 usec.

But the second thread is not fully running yet, it takes another 25 usec or so until it starts writing to the queue.

The actual parallel writing and reading then only takes 25 to 30 usec.

Closing the thread then also takes about 25 to 30 usec.

All in all, the parallel processing (which I guess is what we want to benchmark, right?) is only less than a third of the total time.

I think it would be better to increase the number of elements sent over the queue (at least by 10x, but maybe 100x), in order for most of the measured time to be actually spent during parallel processing.

What do you think?

Hi,

While trying omango out as a crossbeam_channel replacement, I was surprised that the Sender<MyType> going out of scope doesn't close() the channel, and that explicitly closing the sender makes the corresponding rx.recv() immediately fail even if there are messages left in the channel. I could get them with try_recv(), but then would have to deal with the non-blocking API.

Am I missing something, or is omango not intended for the "send finite list of items from one thread to another" usecase ?