5 ms·

Sorry, but it really sounds to me like you're repeating something from documentation or CS 101. Have you ever actually worked on a garbage collector? * ARC is

by t8sr 3y ago

Sorry, but it really sounds to me like you're repeating something from documentation or CS 101. Have you ever actually worked on a garbage collector? * ARC is not deterministic outside of toy examples * The runtime overhead of modern GC algorithms has a lower bound than ARC, and this has been proven formally * Reference counting is usually atomic, so it implies other wonderfully expensive things like CPU cache flushes, memory fences, etc. * The runtime overhead of deferred GC also happens outside of the hot path, and doesn't do unpredictable non-local things if you release a reference at an inconvenient moment * ARC is in fact a GC strategy. E.g. obj-c has autorelease pools that postpone deletion until later, so the hot path doesn't get interrupted if reference count of something reaches zero early. These things are a spectrum. Rust leans a lot on the borrow checker, and both Rust and C++ nudge you toward using fewer heap small allocations because it is inconvenient to use them. This is where a lot of the performance wins come from, not because reference counting somehow shaves off 20% of the program's runtime. In fact, ARC is not only a GC strategy, it is close to being the worst possible GC strategy.

coldtea 3y ago
Sorry, but it really sounds to me like you're repeating something from theorical research on GCs, best cases, and cherry-picking counter-examples. * ARCs non-determinism doesn't matter outside of contrived cases. In practical use it's as deterministic as expected. * The runtime overhead of modern GC algorithms might have been proven formally to have a "lower bound than ARC", but like many things proven formally, it's seldom the case in practice. And this isn't also counting the memory overhead from using GC. Just like the oft-repeated "JIT can be faster than compiled because it has knowledge of the runtime" but in practice that only happens on special cases, and compiled C/C++/Rust still beats its ass. As for the runtime overhead of deferred GC happing "outside of the hot path", and yet every domain with a GC and high load/low latency has historically suffered GC pauses, and GCs have to be reworked to ever more complex byzantine schemes to try to reduce the issue. >*ARC is in fact a GC strategy. E.g. obj-c has autorelease pools that postpone deletion until later, so the hot path doesn't get interrupted if reference count of something reaches zero early. These things are a spectrum. Yes, like cars and 18-wheelers are a spectrum. And C++/Rust is on the other side of that spectrum compared to Java and Go.
- bencyoung 3y ago
  The worst memory performance bug I ever saw turned out to be heap fragmentation in a non-GC system. There are memory allocators that solve this like https://github.com/jemalloc/jemalloc/tree/dev https://github.com/jemalloc/jemalloc/tree/dev but ... they do it by effectively running a GC at the block level As soon as you use atomic counters in a multi-threaded system you can wave goodbye to your scalability too!
- deleted 3y ago
  [deleted]
- t8sr 3y ago
  As you point out, the use of ARC is correlated with languages used in high-performance code. You think it's because ARC is a better way of managing memory, but that's false. Rust is not fast because it uses ARC, it uses ARC because Rust is fast. Rust is fast because it has a good ownership model for memory, because it encourages patterns that mostly get rid of the need to dynamically manage lots of heap objects. These qualities make it cache-friendly, among other things. What's left is generally small enough that even a poor GC strategy like ARC is good enough. A state-of-the-art GC wouldn't be worth the extra complexity in Rust. (And would probably conflict with other features.) Go needs a state of the art GC, because it wants to hide "stack vs heap" from the programmer, and so it puts a lot of things on the heap. If it used ARC, it would be unusable. To people who have worked on programming languages, saying "ARC is good, actually" is either a sign that you're about to present a very nuanced argument informed by decades of experience, or, more likely, that you have no idea what you're talking about. If you're going to make a claim that lies this far outside the mainstream, I'd say the onus to present a good argument is on you, not me. With age, I've found it good to moderate my fervor in proportion to how much I know about a subject. If people learn that you're someone who talks with confidence only about things you know, you'll have an easier time getting them to listen.
  - kaba0 3y ago
    > Go needs a state of the art GC It needs, but unfortunately it doesn’t have. That category is won by Java multiple times.

by t8sr 3y ago

coldtea 3y ago

Sorry, but it really sounds to me like you're repeating something from theorical research on GCs, best cases, and cherry-picking counter-examples. * ARCs non-determinism doesn't matter outside of contrived cases. In practical use it's as deterministic as expected. * The runtime overhead of modern GC algorithms might have been proven formally to have a "lower bound than ARC", but like many things proven formally, it's seldom the case in practice. And this isn't also counting the memory overhead from using GC. Just like the oft-repeated "JIT can be faster than compiled because it has knowledge of the runtime" but in practice that only happens on special cases, and compiled C/C++/Rust still beats its ass. As for the runtime overhead of deferred GC happing "outside of the hot path", and yet every domain with a GC and high load/low latency has historically suffered GC pauses, and GCs have to be reworked to ever more complex byzantine schemes to try to reduce the issue. >*ARC is in fact a GC strategy. E.g. obj-c has autorelease pools that postpone deletion until later, so the hot path doesn't get interrupted if reference count of something reaches zero early. These things are a spectrum. Yes, like cars and 18-wheelers are a spectrum. And C++/Rust is on the other side of that spectrum compared to Java and Go.

bencyoung 3y ago
The worst memory performance bug I ever saw turned out to be heap fragmentation in a non-GC system. There are memory allocators that solve this like https://github.com/jemalloc/jemalloc/tree/dev https://github.com/jemalloc/jemalloc/tree/dev but ... they do it by effectively running a GC at the block level As soon as you use atomic counters in a multi-threaded system you can wave goodbye to your scalability too!
deleted 3y ago
[deleted]
t8sr 3y ago
As you point out, the use of ARC is correlated with languages used in high-performance code. You think it's because ARC is a better way of managing memory, but that's false. Rust is not fast because it uses ARC, it uses ARC because Rust is fast. Rust is fast because it has a good ownership model for memory, because it encourages patterns that mostly get rid of the need to dynamically manage lots of heap objects. These qualities make it cache-friendly, among other things. What's left is generally small enough that even a poor GC strategy like ARC is good enough. A state-of-the-art GC wouldn't be worth the extra complexity in Rust. (And would probably conflict with other features.) Go needs a state of the art GC, because it wants to hide "stack vs heap" from the programmer, and so it puts a lot of things on the heap. If it used ARC, it would be unusable. To people who have worked on programming languages, saying "ARC is good, actually" is either a sign that you're about to present a very nuanced argument informed by decades of experience, or, more likely, that you have no idea what you're talking about. If you're going to make a claim that lies this far outside the mainstream, I'd say the onus to present a good argument is on you, not me. With age, I've found it good to moderate my fervor in proportion to how much I know about a subject. If people learn that you're someone who talks with confidence only about things you know, you'll have an easier time getting them to listen.
- kaba0 3y ago
  > Go needs a state of the art GC It needs, but unfortunately it doesn’t have. That category is won by Java multiple times.