Re:The Rust compiler has gotten faster again
by sizediterable on Thursday November 11, 2021 @10:44PM
(#29196121)
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).
Re:The Rust compiler has gotten faster again
by gnulinux on Friday November 12, 2021 @04:48AM
(#29197724)
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.
Re:The Rust compiler has gotten faster again
by Const-me on Friday November 12, 2021 @12:48AM
(#29196636)
> 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.
Re:The Rust compiler has gotten faster again
by sizediterable on Friday November 12, 2021 @11:57AM
(#29201550)
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.
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.