4 ms·

For what is worth, you can opt-into reference counting and internal mutability with container types (Arc/Rc, Cell/RefCell, RwLock/Mutex), and get the same perfo

For what is worth, you can opt-into reference counting and internal mutability with container types (Arc/Rc, Cell/RefCell, RwLock/Mutex), and get the same performance characteristics as a GC language (but without a JIT) for the cost of more complex types in your signatures. Edit: > the constraints of the borrow checker make things like tree structures at least an order of magnitude harder to get right The constraints of the borrow checker make those things more unlikely to compile without extra ceremony. The likelihood of getting them right is orthogonal from making the compiler "happy", even in Rust but specially in other languages. The way I've heard it described is that Rust is a language where you get the hangover first. It upfronts dealing with the error conditions of your problem space in a way that (you can argue) hinders the exploration phase, but that makes of a very quiet maintenance phase.

sizediterable 5y ago
People like to bring up reference cycles a lot as if it's always a deal-breaker, but for short-lived processes it kind of seems like a non-issue. Anecdotally, we've seen Instagram get overall gains by disabling GC in Python (which will still do reference counted cleanup).
- gnulinux 5y ago
  Exactly, I like implementing compilers and I personally never bother with anything other than reference counting nowadays. Ref count gives a very easy to reason semantics. So I count as a feature in my language even if it's slower than GC. Moreover, some of the "memory leak" discussions nowadays miss the biggest issue behind memory leak, which is resource allocation. Some people measure memory leak as the # bytes that process didn't deallocate at the time of exit.
Const-me 5y ago
> and get the same performance characteristics as a GC language Pretty sure modern state of the art GCs, like the ones found in Java or .NET runtimes, are way more efficient than reference counting. Reference counters have that unfortunate RAM access pattern where the counter is frequently updated from multiple threads concurrently. On modern processors, this means concurrent access to a cache line by different CPU cores. These cache coherency protocols are pretty slow. On many CPUs, reading a cache line recently modified by another core costs 300-500 clock cycles, even more expensive than a cache miss and roundtrip to system RAM.
- sizediterable 5y ago
  Python is experimenting with a novel approach where objects have two reference counts, one exclusively for the owning thread and another for all other threads, improving performance when most of the increments/decrements are done by the owning thread. https://lwn.net/Articles/872869/ https://lwn.net/Articles/872869/
- pjmlp 5y ago
  They are, specially when ARC marketing from Apple gets validated. https://github.com/ixy-languages/ixy-languages https://github.com/ixy-languages/ixy-languages

sizediterable 5y ago

People like to bring up reference cycles a lot as if it's always a deal-breaker, but for short-lived processes it kind of seems like a non-issue. Anecdotally, we've seen Instagram get overall gains by disabling GC in Python (which will still do reference counted cleanup).

gnulinux 5y ago
Exactly, I like implementing compilers and I personally never bother with anything other than reference counting nowadays. Ref count gives a very easy to reason semantics. So I count as a feature in my language even if it's slower than GC. Moreover, some of the "memory leak" discussions nowadays miss the biggest issue behind memory leak, which is resource allocation. Some people measure memory leak as the # bytes that process didn't deallocate at the time of exit.

Const-me 5y ago

> and get the same performance characteristics as a GC language Pretty sure modern state of the art GCs, like the ones found in Java or .NET runtimes, are way more efficient than reference counting. Reference counters have that unfortunate RAM access pattern where the counter is frequently updated from multiple threads concurrently. On modern processors, this means concurrent access to a cache line by different CPU cores. These cache coherency protocols are pretty slow. On many CPUs, reading a cache line recently modified by another core costs 300-500 clock cycles, even more expensive than a cache miss and roundtrip to system RAM.

sizediterable 5y ago
Python is experimenting with a novel approach where objects have two reference counts, one exclusively for the owning thread and another for all other threads, improving performance when most of the increments/decrements are done by the owning thread. https://lwn.net/Articles/872869/ https://lwn.net/Articles/872869/
pjmlp 5y ago
They are, specially when ARC marketing from Apple gets validated. https://github.com/ixy-languages/ixy-languages https://github.com/ixy-languages/ixy-languages