3 ms·
GCs have not come far enough if you care about performance. A modern "fast" GC has latencies similar to disk I/O on modern storage. We don't make a habit of ra
by jandrewrogers 3y ago
GCs have not come far enough if you care about performance.
A modern "fast" GC has latencies similar to disk I/O on modern storage. We don't make a habit of randomly dropping a blocking disk I/O in the middle of a performance critical path, and disk I/O is less likely to pollute your CPU cache as a side effect than a GC. Given that performance-optimized code is routinely designed to eliminate the overhead of even context switches (e.g. thread-per-core architectures) to great benefit and GC pauses are much more expensive than a context switch even when "fast", it is difficult to develop a theory of how a GC does not have an adverse impact on performance.
You could try to make the argument that most people writing Rust don't care about performance so it doesn't matter, but that is likely to be controversial at the least.
- pebal 3y agoYou can have completely concurrent GC, without pausing threads. https://github.com/pebal/sgcl https://github.com/pebal/sgcl
- jandrewrogers 3y agoHow does this work with standard thread-per-core architectures used in high-performance systems? Sharing state with a GC thread defeats the entire purpose even if you had a dedicated GC thread for each working core to reduce contention, since the entire point is to all but eliminate atomics and cache coherency overhead. This doesn't address the issue with GCs in high-performance systems, it just turns it into a different kind of problem.
- pebal 3y agoYou either pause the worker threads or share the state, there's no other way. However, the GC thread does not modify the data state.
- _se 3y agoSo, your pauseless GC pauses or requires some form of resource contention (probably mutex-based) to share the state. It's not possible to have a pauseless GC in thread per core, which immediately rules it out for HPC. These are the types of things that the "GC for everything" crowd admits that they don't understand when making such statements.
- pebal 3y agoI misunderstood you. State is shared by mutator threads using atomic::store(memory_order_release). SGCL never stops threads and does not use locks to share state.
- deleted 3y ago[deleted]