Hacker News Reader

Comment by DannyBee | Hacker News Reader

Ignoring all the other problems with this article that have been pointed out around definitions, it also claims that lockless is slow anyway. Without giving literally any data.

Good news: it's not slow

Let's take rust, which has an oddly thriving ecosystem of lockless mpsc/mpmc/etc queues, and lots of benchmarks of them in lots of configurations.

The fastest ones easily do at least 30 million elements/second in most configurations. The "slowest" around 5-10.

So the fastest is doing 33ns per element and the slowest is 100ns.

Which is probably why the article offers no data. It's not actually slow. It's actually really fast when done well.

View on HN

I have always found MPMC ring buffers to have worse tails than pointer-based MPMC queues. These are very unfashionable (especially in rust) but can be made wait-free with a single atomic for readers and writers. The SPSC ring buffer is perfect, but adding either more producers or more consumers makes the whole thing have terrible pathologies.

Reading the article again, this lockless bag idea also needs two atomic writes on every operation.

SPMC ring buffer or SPMC "disruptor" aren't that bad. Multiple producers in a general ring buffer definitely introduce a lot of issues.

The "disruptor" pattern has some significant problems with tail performance (around pathological OS scheduling) if you aren't running one thread per core the way LMAX designed it.

I read "slow" and "fast" in the article as comparative term. "slower than" what the writer has seen in other cases.

Absolute ms doesn't prove much unless you put it in comparison with other best.

Without any data it's impossible to even tell what this means or whether it matters. IE even as a comparitive term it's useless without real data.

Theoretically better (which is questionable at best in this case) doesn't mean anything useful if it doesn't actually matter in practice, or is always worse in pracftice.

As noted by other commenters, the point I was trying to get across is that the way we implement lockless channels is suboptimal and could be made faster from a theoretical standpoint.

In my benchmarks[1], the average processing time for an element is 250ns with 4 producers and 4 consumers contending heavily. That's terrible! Even if your numbers are correct, 100ns is a bit faster than two round trips to RAM while 33ns is about three round trips to L3 and ~100x slower than spamming a core with add operations. That's slow.

[1]: https://github.com/SUPERCILEX/lockness/blob/master/bags/benc... $ cargo bench -- 8_threads/std_mpmc

It's only terrible if it actually matters?

Also it doesn't look like you are using any of the optimized lockless implementations like crossfire/etc, so not sure what this actually proves?

Why would lockless be slower? Is it ever slower?

Reply on news.ycombinator.com