deque2 VS slice_deque

I’m also not much of a Go programmer, but looking at the benchmark code it doesn’t actually use the values after they are retrieved, so if the compiler is smart it may never have to check the runtime of the type. It does, however, have to wrap the primitive in the any type, which seems to be what’s making it slow.

Question for Go programmers: does using the any type result in an additional memory lookup if the wrapped type is a sized primitive like an int, or is the value stored directly alongside the type information?

https://github.com/sekoyo/deque/blob/86df0003850acaf3039c2d6...

> It's not an attack on the wording, but the correctness of your first bullet point. `unsafe` is appropriate for the initialization of a ring buffer in Rust. That's true for using `mmap` or anything in "pure" Rust using the allocator API to get the most idiomatic representation (which can't be done in safe or stable Rust). It's not one line. It's also not platform dependent, the code is the same on MacOS, Linux, and Windows the last I tried it.

We're not talking about the same thing then.

I'm talking about this code here: <https://github.com/gnzlbg/slice_deque/tree/master/src/mirror...> It is absolutely platform specific.

Yes, most ring buffer implementations feature a little bit of `unsafe` code. No, it doesn't make sense to say "I have a tiny amount of `unsafe` already, so adding more has no cost."

> But if your bottleneck is determined by the frequency at which channels get created or how many exist then I would call architecture into the question. ... This last month I've written a lock-free ring buffer to solve a problem and there's exactly one in an application that spawns millions of concurrent tasks.

Okay, but a lot of applications or libraries are written to support many connections, and you don't necessarily know when writing the code (or even when your server receives them) if those connections will be just cycled very quickly or will be high-throughput long-lived affairs. Each of those probably has a send buffer and a receive buffer. So while it might make sense for your application to have a single ring buffer for its life, applications which churn through them heavily are completely valid.

There is a single contiguous memory allocation, which mirrors itself.

One thread produces elements and pushes them at the tail (e.g. I/O bytes, in batch), and one thread consumes as many elements as possible in batch from the other end (e.g. all bytes available, in batch).

The mirror is required to allow processing all elements in the deque as if they were adjacent in memory.

This is the library i am using, the array contains an explanation : https://github.com/gnzlbg/slice_deque