Optimizing a lock-free ring buffer • Hacker News Board

Re: Optimizing a lock-free ring buffer

#61

Post by dalvrosa » Thu, Mar 26, 2026, 6:42 PM UTC

dijit wrote: post #60

dalvrosa wrote: post #46

Earlier quoted context omitted.

Agreed. For benchmarking I used this https://github.com/david-alvarez-rosa/CppPlayground/blob/mai... > which relies on GoogleBenchmark and pins producer/consumer threads to dedicated CPU cores What else could be improved? Would like to learn :) Maybe using huge pages?

kernel tickrate is a pretty big one, most people don't bother and use what their OS ships with. Disabling c-states, pinning network interfaces to dedicated cores (and isolating your application from those cores) and `SCHED_FIFO` (chrt -f 99 ) helps a lot . Transparent hugepages increase latency without you being aware of when it happens, I usually disable that. Idk, there's a bunch but they all depend on your use-cas…

Thanks. Do you happen to know why hyperthreading should be disabled?

In prod most trading companies do disable it, not sure about generic benchmarks best practices

Re: Optimizing a lock-free ring buffer

#62

Post by dijit » Thu, Mar 26, 2026, 6:44 PM UTC

dalvrosa wrote: post #61

dijit wrote: post #60

Earlier quoted context omitted.

kernel tickrate is a pretty big one, most people don't bother and use what their OS ships with. Disabling c-states, pinning network interfaces to dedicated cores (and isolating your application from those cores) and `SCHED_FIFO` (chrt -f 99 ) helps a lot . Transparent hugepages increase latency without you being aware of when it happens, I usually disable that. Idk, there's a bunch but they all depend on your use-cas…

Thanks. Do you happen to know why hyperthreading should be disabled? In prod most trading companies do disable it, not sure about generic benchmarks best practices

It eliminates cache contention between siblings, which leads to increased latency (randomly)

Re: Optimizing a lock-free ring buffer

#63

Post by dalvrosa » Thu, Mar 26, 2026, 6:45 PM UTC

loeg wrote: post #47

superxpro12 wrote: post #24

Earlier quoted context omitted.

I've taken an interest in lock-free queues for ultra-low power embedded... think Cortex-m0, or even avr/pic. Things get interesting when you're working with a cpu that lacks the ldrex/strem assembly instructions that makes this all work. I think youre only options at that point are disable/enable interrupts. IF anyone has any insights into this constraint I'd love to hear it.

For ultra low-power embedded, wouldn't a mutex approach work just fine? You're running on a single core anyway.

I'm not sure about the single-core scenario, but would love to learn if someone else wants to add something

In reality multiple threads for single core doesn't make much sense right?

Re: Optimizing a lock-free ring buffer

#64

Post by brcmthrowaway » Thu, Mar 26, 2026, 7:01 PM UTC

Random q: What was the first cpu to support atomic instructions?

Re: Optimizing a lock-free ring buffer

#65

Post by brcmthrowaway » Thu, Mar 26, 2026, 7:04 PM UTC

Is there a C library that I can get these data structures for free?

Re: Optimizing a lock-free ring buffer

#66

Post by jeffbee » Thu, Mar 26, 2026, 7:13 PM UTC

dalvrosa wrote: post #61

dijit wrote: post #60

Earlier quoted context omitted.

kernel tickrate is a pretty big one, most people don't bother and use what their OS ships with. Disabling c-states, pinning network interfaces to dedicated cores (and isolating your application from those cores) and `SCHED_FIFO` (chrt -f 99 ) helps a lot . Transparent hugepages increase latency without you being aware of when it happens, I usually disable that. Idk, there's a bunch but they all depend on your use-cas…

Thanks. Do you happen to know why hyperthreading should be disabled? In prod most trading companies do disable it, not sure about generic benchmarks best practices

There are some microarchitectural resources that are either statically divided between running threads, or "cooperatively" fought over, and if you don't need to hide cache miss latency, which is the only thing hyperthreading is really good at, you're probably better off disabling the supernumerary threads.

Re: Optimizing a lock-free ring buffer

#67

Post by jeffbee » Thu, Mar 26, 2026, 7:15 PM UTC

brcmthrowaway wrote: post #64

Random q: What was the first cpu to support atomic instructions?

I don't know but the IBM 360 and the DEC PDP-10 both had them. Those are the earliest systems I ever saw.

Re: Optimizing a lock-free ring buffer

#68

Post by nitwit005 » Thu, Mar 26, 2026, 7:18 PM UTC

It would be nice to have an example use case where the technique would show a benefit.

It seems relatively rare to have a single producer and consumer thread, and be worth polling a ring buffer.

Re: Optimizing a lock-free ring buffer

#69

Post by jeffbee » Thu, Mar 26, 2026, 7:18 PM UTC

It's lock-free because it uses ordered loads and stores, which is also how you implement locks. I find the semantic distinction unconvincing. The post is really about how slow the default STL mutex implementation is.

Re: Optimizing a lock-free ring buffer

#70

Post by ohazi » Thu, Mar 26, 2026, 8:59 PM UTC

nitwit005 wrote: post #68

It would be nice to have an example use case where the technique would show a benefit. It seems relatively rare to have a single producer and consumer thread, and be worth polling a ring buffer.

I use my own very similar version of this spsc lock-free ring buffer on almost every embedded project I work on that has to stream any sort of sampled data (e.g. audio). You can even have the consumer end be a DMA into something like a uart or USB peripheral so your microcontroller userspace doesn't have to touch the hardware.