2 ms·
Channels and RCU can often be better for performance as well. I have run into scaling issues due to contention way too many times. Sometimes just because two th
by VorpalWay 11mo ago
Channels and RCU can often be better for performance as well. I have run into scaling issues due to contention way too many times. Sometimes just because two things were in different parts of the same cache line.
Sharing as little mutable state as possible is often the best way to scale to a large number of CPU cores. RCU can help with that if you have data that is mostly read but rarely written. If your workload is balanced or even write heavy RCU is probably not a good option.
I have even had to redesign because I had too much contention on plain old atomic reference counters, almost 30 % of my runtime was reference counting of a small number of specific Arcs, and hardware performance counters pointed at cache line contention. I redesigned that code to avoid Arcs entirely which also allowed some additional optimisations, resulting in cutting approximately 40 % of my runtime in total.
So, each specific use case should be approached individually if you care about performance. And always profile and benchmark. If the code isn't performance critical, by all means do what you think is most maintainable. But measure, because you are probably wrong about what part of your code is the bottleneck unless you measure.
- pdimitar 11mo agoVery interesting, I want to learn more. How do you diagnose contention on atomic counters? And how do you diagnose cache line contention? And how do you rewrite that code away from Arc-s?