7 ms·
Seems like we could just as easily stop using garbage collection. ... or even go back to reference counting / smart pointers and just live with the “limitation”
by mailslot 7y ago
Seems like we could just as easily stop using garbage collection. ... or even go back to reference counting / smart pointers and just live with the “limitation” that we can’t have circular references.
- hnaccy 7y agoWhy limitation in quotes? Do you feel it is not one in practice?
- mailslot 7y agoI argue that some limitations, like clear resource ownership, are good... but there are still workarounds that aren’t too arduous. Weak pointers and the like are decent enough abstractions to handle the rare case... or just going manual. It’s not a limitation in practice, no. It hasn’t been a problem for me in over a decade in a multitude of languages. On Java codebases? I’ve witnessed some frightening levels of sloppiness that are only solvable with a profiler.
- Eric_WVGG 7y agodoesn’t seem cool to admire Apple technologies, but ARC seems to work amazingly well with zero CPU overhead
- seandougall 7y agoIt’s not zero — those -retain and -release calls still exist when necessary and have a small penalty — but it does minimize them well, and is lower overhead and vastly more predictable than GC.
- favorited 7y agoIt's a little better than that, because the overhead of ObjC method dispatch is avoided. There are no calls to -retain or -release (if the receiver hasn't overridden those methods), it's just a C function call to objc_release et al. No objc_msgSend involved.
- kllrnohj 7y agoIt's not at all zero CPU overhead, not even close. retain & release are thread-safe, meaning atomic ref count. Very comparable in cost to std::shared_ptr<T> or Rust's Arc<T>. Both of which also automatically insert the calls to inc & dec ref counts. It's cool that you don't need to bother with specifying the type as being std::shared_ptr<T> or Arc<T>, but it's not particularly novel, either. It's "just" syntax sugar (or lack of syntax sugar I guess?)
- vlovich123 7y agoAlmost but not quite. Clang has very special rules around ARC that allow it to perform additional optimizations that would otherwise be illegal [1]. [1] https://clang.llvm.org/docs/AutomaticReferenceCounting.html#arc-optimization https://clang.llvm.org/docs/AutomaticReferenceCounting.html#...
- kllrnohj 7y agoThat just lets it release earlier, not retain/release less often. ARC can't do anything magic here vs. something like really careful use of std::move & const references.
- favorited 7y agoARC optimizations do let it retain/release less often. For example, instead of a callee adding the return value to an autorelease pool then having the caller immediately retain the returned value, the autorelease+retain pair can be elided entirely.
- kllrnohj 7y ago> For example, instead of a callee adding the return value to an autorelease pool then having the caller immediately retain the returned value, the autorelease+retain pair can be elided entirely. Are you just referring to standard RVO? If you return a std::shared_ptr in C++ today you won't get the equivalent of retain+release, either, RVO avoids that.
- ZitchDog 7y agoWhy scare quote "limitation"? It literally is a limitation, since it prevents me from doing something in code that can be useful at times. It certainly has tradeoffs.
- flukus 7y agoIt's not a hard limitation, the fallback is some degree of manual memory management.
- SmooL 7y agoWhich has been shown time and time again to be the source of many serious software bugs and exploits
- soup10 7y agooooo manual memory management scary. the absolute state of web programmers today
- aidenn0 7y agoI have over a decade of professional experience entirely in C and C++. I believe that manual memory management is the wrong choice for the vast majority of applications. It is error prone and often slower than garbage collection.
- p_l 7y agoReference counting nor "manual" memory management are not faster than GC by themselves. Both tend to have pretty bad slowdowns that tend to result in optimizations... By batching operations similar to "GC pass", because there are different metrics of performance and occasional pause appears to be good compromise for most. Personally I'm partial to deterministic schemes akin to IBM Metronome, where GC runs in bounded static time.
- aidenn0 7y agoMany tracing GC algorithms are considerably faster than reference counting.
- legulere 7y agoDepending on the workload different memory allocation strategies perform better or worse. GC systems usually even have the fastest allocation. The only problem is that you see deallocation as one big block that is completely disconnected from allocation.
- p_l 7y agoIn throughput-optimized GC setups (not latency optimized) that's the case. Though free(), despite being seemingly "constant", can have unpredictable pause times as well when you hit a bad point.
- incompatible 7y agoWhy would a reaction to a faster / low resource GC method be to stop using GC?
- p_l 7y agoBecause people aren't taught about GC or memory management at all, so cheap soundbites about "GC being bad" from old survives as "wisdom"
- chmod775 7y agoReference counting is already slower than having a GC in most practical applications, not to mention that having no circular references may make the code where you need 'em either slower or means you'll have to write a workaround, which is often also overhead and makes things more complicated.
- tjoff 7y agoThe benefit of not using GC is improved understanding of the code and a better architecture. These things will also lead to better performance. GC was a mistake. The main reason it is still used outside scripting languages is the notion that non-GC languages need to be low level. Which in practice is kind of true just because we haven't had any real competition in that area.
- hasahmed 7y agoGc was a mistake? On what possible authority can you make such a claim?
- tjoff 7y agoIt's not that controversial of a statement. The choice has largely been dictated by the fact that non-GC meant C or C++, and it is not hard to find reasons to avoid them. Now we also have rust, but rust is new and also has a low-level aura, making comparisons to high-level languages difficult. That Go has a GC is a shame, such a missed opportunity.
- p_l 7y agoNot having GC in no way improves understanding of architecture or gives better performance. Hordes of C/C++ programmers that don't understand memory management but swear by malloc()/free() are a good example of that. And it's not like C/C++ are only language without GC, they are just popular now. Typical programmer is taught nothing about memory management, till maybe they learn bits and pieces (often by hearsay and cargo culting). It doesn't matter if we're talking manual or automatic. Without such understanding one cannot write performant code or make a good architecture. Also - a good working definition of low-level language is language that makes you care about things irrelevant to your task...
- xxs 7y agoRef counting is worse than GC. Ref counting: deeper pipelines, branch predictor extra load. And when you need multithreaded/concurrency it goes to atomic operations, cache coherency traffic, memory and compiler barriers.