Hacker News Reader

Comment by Const-me | Hacker News Reader

> that should be practically zero-cost on x86

It’s practically zero cost when uncontested. When contested, the instructions with that `lock` prefix are concurrently accessing a single cache line from multiple cores at the same time.

These cache coherency protocols are relatively slow. On some processors, reading a cache line recently modified by another core can cost 300-500 cycles, way more expensive than a cache miss and roundtrip to off-chip memory.

View on HN

That is also true. But as said, I haven't yet personally run into a case where refcounting was contested to a point of making it an optimisation priority.

I think one the main use-cases for RCU in kernel is to alleviate the need for atomic reference counting in places where it would significantly impact performance. What you are saying might be indicative of one of the points that author raised: People mostly use Rust in non-system contexts where they don't really care that much about performance and would be better served by GC-ed language with runtime.

I'm not sure what counts as a non-system context these days. Most of my experience with using Rust in production was with a message queue type of service, where the desire was to minimize latency and to have consistent performance over prolonged use. I did make an initial prototype with C#, but things were much easier to make work well on both counts with Rust and Tokio.

> a message queue type of service, where the desire was to minimize latency and to have consistent performance over prolonged use.

Your requirements are probably similar to this C# queues class: https://github.com/Const-me/Vrmac/blob/master/VrmacVideo/Aud... That library decodes and plays realtime video + audio, both low latency and consistent performance over prolonged use were rather important. BTW that code runs on Raspberry Pi4, CPU performance is a fraction of what you’d expect on modern desktops or servers.

Reply on news.ycombinator.com