5 ms·
1 - The tradeoff between latency, throughput and memory-use of tracing GCs is universal and language-independent. Some implementations may be better than the ot
by pkolaczk 6y ago
1 - The tradeoff between latency, throughput and memory-use of tracing GCs is universal and language-independent. Some implementations may be better than the others, but I haven't seen an implementation that is good in all three aspects.
2 - I've seen this repeated on the Internet many times, but there is little scientific evidence, and the one available is quite contradictory. I recall a paper where authors argued that replacing the old-gen collector with reference counting actually improved performance. So this is definitely not universally true, and depends on many factors such as imposed constraints on memory overhead and usage patterns. It is easy to make GC good when you only create short-lived objects and allow it to use 10x more memory than needed. But things get pretty hairy when you also want low-pauses and low memory overhead and objects live longer (e.g. cache-like use cases). Also the number of reference counted objects in C++/Rust programs is typically orders of magnitude lower than the number of GCed objects in GCed languages, so even if ref-counting was less efficient per-object lifetime, it is not globally less efficient.
3 - Agree, but "value types" have been present in C/C++/Rust/Swift/D/C# and dozens of other languages for ages, so, unless you're forced to work on a legacy Java project, why wait? You can become productive in Rust in less time than they will be able to ship Valhalla.
- pjmlp 6y ago1 - Just like manual memory management isn't good in all aspects and before the FOSS wave there were companies whose only business was selling specialized versions of malloc()/free(). 2 - Really? Here is one to start with, https://github.com/ixy-languages/ixy-languages https://github.com/ixy-languages/ixy-languages. Enjoy the RC high performance from Swift. Additional SIGPLAN and ACM papers can be provided. The fact is that when RC gets fine tuned for performance, it is a tracing GC in disguise, with its background threads for deferred releases, like C++/WinRT is currently doing with COM/UWP. 3 - It takes some time to catch up with 25 years of libraries, OS and IDE support
- pkolaczk 6y ago2 - and your link only shows that Go, Java and C# have substantially lower performance than C and Rust on this task. So that doesn't refute my point. As I said, the whole trick relies on the fact that these languages don't need so much GC in the first place. Reference counting in Rust or C is something you do as the last resort. It doesnt matter it is slower per-single-object, when you have 1000x fewer objects. 3 - Mature doesn't mean all of it is always better. Take Cargo vs Maven/Gradle. Or libraries for async programming. Also not everything needs to be written from scratch.
- pjmlp 6y agoMicro-benchmarks are meaningless if the project hard deadlines have been met and customer is happy with the result. The point of my link was about Swift RC performance, Rust and C aren't using it.
- majewsky 6y ago> You can become productive in Rust in less time than they will be able to ship Valhalla. Yeah, but they'll ship Valhalla before you rewrite your existing 4M LOC Java application.
- higerordermap 6y agoApple fanboys or rust fanboys who talk about superiority of ARC on programming forums are also likely not knowing computer science terms like cache and contention.