4 ms·
I agree with a lot of what he says. He gets something subtly wrong though: GC barriers are waaaaay cheaper than ARC, in the limit when you optimize them. Libau
by pizlonator 5y ago
I agree with a lot of what he says.
He gets something subtly wrong though: GC barriers are waaaaay cheaper than ARC, in the limit when you optimize them. Libauto had expensive barriers, but as Chris said, it’s not super interesting since it was overconstrained. But the production high-perf GCs tend to have barriers that are way cheaper than executing an atomic instruction. JSC’s GC has barriers that basically cost nothing, and that’s not unusual. It’s true that low latency GCs tend to have barrier overheads that are higher than high throughput GCs, but even then, the cost isn’t anything like atomic inc/dec. The barrier overhead in RTGCs is often around 5-15% except for the esoteric algorithms nobody uses.
Also, GCs trivially give you safety even if you race to store to a pointer field. ARC doesn’t, unless you introduce additional overheads.
Does what I say mean that ARC is bad? Heck no, ARC is super impressive. But it does mean that it’s a good idea to weigh ARC versus GC as a determinism versus speed decision, and accept that if you chose ARC, you lost some speed.
Oh but ARC also let’s you do CoW better than what a GC could give you, so for some languages ARC is a speed win over any possible GC because it’ll let you do fewer copies. I think that’s true in Swift. But if you don’t have CoW then GCs are def faster.
- vvanders 5y agoI think his point about the amount of research done on ARC vs GC was interesting. Only recently have we see things like biased reference counting[1] that can significantly reduce the overhead of ARC. [1] http://iacoma.cs.uiuc.edu/iacoma-papers/PRES/present_pact18.pdf http://iacoma.cs.uiuc.edu/iacoma-papers/PRES/present_pact18....
- deleted 5y ago[deleted]
- pjmlp 5y agoReference counting is the oldest garbage collection algorithm, it has seen plenty of research. What keeps being overseen is the amount of engineering to make reference counting perform in modern hardware, effectively overlaps with other garbage collection optimizations.
- tialaramex 5y ago> What keeps being overseen is the amount of engineering ... You probably wanted "overlooked" here. Even though "seen" and "looked" are similar in meaning, "overseen" and "overlooked" are not. This is a subtle but important distinction in English. https://grammarist.com/usage/oversee-vs-overlook/ https://grammarist.com/usage/oversee-vs-overlook/ Historically you could choose "oversee" when you would today use "overlook" or vice versa, but these usages went from archaic to actively disapproved. One remnant though is you would still use "overlook" in a sentence like "Atop the hill, the old castle overlooks the whole town".
- waqf 5y agoAnd yet (depending on how it is used) "oversight" often refers to an instance of overlooking, rather than of overseeing. It seems remiss of Grammarist to write an entire page without mentioning that.
- tialaramex 5y agoGood point. Example showing the two contrasting meanings of the word "oversight" in modern English: At m.d.s.policy it was our view that Symantec management had inadequate oversight of Symantec's Certificate Authority and as a result on several occasions over an extended period an important oversight relating to the name validation procedures at CrossCert, a Korean business authorised by Symtanec to issue on their behalf - occurred without being detected by Symantec. This definitely resulted in undetected misissuance. As a result of our efforts to fix this problem Symantec sold their entire CA business to DigiCert, and CrossCert became merely a reseller of DigiCert's products (including "Symantec" branded certificates) This meant that now DigiCert's trustworthy management exercised oversight over all issuance of certificates from the new CA hierarchy even when the certificates had "Symantec" branding - while an oversight by CrossCert, such as failing to verify the identity of a customer, would no longer cause misissuance because DigiCert would independently use the Ten Blessed Methods.
- pizlonator 5y agoLol biased ref counting. I tried that years ago. It’s super fast for serial workloads or very simple parallel ones. I would avoid it for anything real.
- celeritascelery 5y agoIn the article > The performance side of things I think is still up in the air because ARC certainly does introduce overhead. As you said, they can both introduce overhead, but the ARC overhead is way worse. Really the only reason to use garbage collection (which is really complex) over ARC (which is simple) is the performance and control you get. Otherwise it would not be worth the implementation cost. The question is not “up in the air” on performance; production-grade GC’s are a clear winner. I would even be doubtful that CoW could make up the difference. But I would be interested to see data suggesting otherwise.
- nu11ptr 5y agoNo doubt straight up ARC with refcounting bumps on every function call,etc. vs a good GC with same allocation paths...a good GC will smoke it. No question. But that isn't how I read what Lattner said here, and I've been thinking similar things. Essentially with ARC the goal is to cheat (to be fair with tracing GC it is as well, just in different ways). And you cheat by implementing an ownership/borrow collector type system behind the scenes for getting rid of the need for RC on most of your objects. Once you do that, you have GC competing with stack allocation + some malloc/free scattered in. It becomes a much more interesting fight.
- adgjlsfhk1 5y agonote that GCs are starting to cheat too. Julia (for example) is in the process of implementing compile time escape analysis which will be used to (among other things) remove allocations as long as the compiler can prove you won't notice.
- hayley-patton 5y agoJava, Go and JavaScript implementations do escape analysis already.
- gameswithgo 5y ago