4 ms·
You need more than that. Reference counting amplifies reads into writes. To ameliorate that (somewhat) you need to keep the references separate from the data
by rwmj 4y ago
You need more than that. Reference counting amplifies reads into writes. To ameliorate that (somewhat) you need to keep the references separate from the data (a particular problem with Rust). Otherwise you end up with lots of writes scattered all over memory, causing false sharing and lots of unnecessary communication over buses between your cores. One way to do this is to keep the references together in separate cache lines or pages, away from the data. And this only partly alleviates the problem.
- zarzavat 4y agoWhile this is true on a microscopic scale, the motivation for using RC is macroscopic: to release memory ASAP to get predictable, low memory usage. From the RC point of view the real enemy is swap and the memory management system's primary objective is to eliminate swap.
- rwmj 4y agoTo summarise: - your application is using close to 100% available RAM - you don't care about the impact of all those extra writes clogging up CPU caches and bouncing cache lines back and forth across internal buses - you can't afford to pay for a small amount of extra RAM In that case reference counting sounds ideal. Good luck!
- zarzavat 4y agoThis was exactly Apple's reasoning for using refcounting in Swift. Although, as I understand it they worked around problem (2) by building their own silicon. If you're on the server then just buy more RAM and use a GC, I agree. But if you're making consumer software then buying more RAM isn't an option. Additionally, RAM costs battery life even when it isn't in use.
- JonChesterfield 4y agoPrompt is even better than predictable. In particular, reliably knowing the refcount on immutable data (in the persistent structure sense) has reached one means you can mutate it undetectably.