Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reference count, don't garbage collect

kevinlawler.com

Post reply on HN
Print view View original

271–280 of 415 posts

Re: Reference count, don't garbage collect

#271

Post by bitcharmer »

ncmncm wrote: post #238
nemothekid wrote: post #139

Earlier quoted context omitted.

> What’s P&L? I meant PL research as in programming language research. Not sure why my brain decided to put an & there. > Does Java have verbose semantics? I think Java’s semantics are pretty neat and concise. Where’s the verbosity? `FizzBuzzEnterpriseEdition` and is a meme for a reason. That said I'm sure Java idioms written today is a lot more sane than they were around the time everyone decided to rewrite everythi…

"Profit and loss"

Been working in fintech (HFT) for well over a decade. Never seen profit and loss abbreviated to P&L. It was always PnL

Re: Reference count, don't garbage collect

#272

Post by pjmlp »

musicale wrote: post #125
yyyk wrote: post #73

Reference counting is garbage collection, just a different strategy - and all these strategies tend to blur to the same methods eventually, eventually offering a latency-optimized GC or a throughput-optimized GC. Swift is inferior here because it uses reference counting GC without much work towards mitigating its drawbacks like cycles (judging by some recent posts, some of its fans apparently aren't even aware RC has…

Maybe Apple just hires mediocre developers (I certainly have lots of complaints about their software and UI issues, but I would probably suspect management/priorities/schedules rather than the technical staff) but they implemented GC and Automatic Reference Counting for ObjC and found that the latter resulted in better and more consistent responsiveness, which is probably what most users care about in apps. (Apps sti…

https://github.com/ixy-languages/ixy-languages

The real reason why a tracing GC was a failure in Objective-C was due to the interoperability with the underlying C semantics, where anything goes.

The implementation was never stable enough beyond toy examples.

Naturally automating the Cocoa release/retain calls made more sense, given the constraints.

In typical Apple fashion they pivoted into it, gave the algorithm a fancy name, and then in a you're holding it wrong style message, sold their plan B as the best way in the world to manage memory.

When Swift came around, having the need to easily interop with the Objective-C ecosystem naturally meant to keep the same approach, otherwise they would need the same machinery that .NET uses (RCW/CCW) to interop with COM AddRef/Release.

What Apple has is excellent marketing.

Re: Reference count, don't garbage collect

#273

Post by pjmlp »

viktorcode wrote: post #236
yyyk wrote: post #73

Reference counting is garbage collection, just a different strategy - and all these strategies tend to blur to the same methods eventually, eventually offering a latency-optimized GC or a throughput-optimized GC. Swift is inferior here because it uses reference counting GC without much work towards mitigating its drawbacks like cycles (judging by some recent posts, some of its fans apparently aren't even aware RC has…

Putting both under the same term is meaningless. Reference counting and Garbage Collection have very clear difference: when the referenced objects are destroyed (not deallocated). In RC it happens when the count reaches zero. In GC it happens some time later. That difference is crucial for having or not having deterministic performance in your program.

Chapter 5, https://gchandbook.org/

Re: Reference count, don't garbage collect

#274

Post by olvy0 »

osigurdson wrote: post #191
shwestrick wrote: post #12

This debate has gone round and round for decades. There are no hard lines; this is about performance tradeoffs, and always will be. Perhaps the biggest misconception about reference counting is that people believe it avoids GC pauses. That's not true. Essentially, whereas tracing GC has pauses while tracing live data, reference counting has pauses while tracing garbage. Reference counting is really just another kind…

One thing that is particularly strange in C#, is objects can respond to events / delegates after they have gone out of scope. It can be quite a while before the object is actually collected - especially if it ends up on the large object (85K+) heap. This seems like an incredibly leaky abstraction to me. The whole "using" concept is a bit of an abomination as well = though getting better. The issue with GC is it is a…

It's a "feature" on the language, like others said below.

The codebase I work with has had many pathological crashes due to this behavior.

So basically in C# when you use += to subscribe to events, in a big system where lifetimes of objects are independent of each other, you're back to a C/C++ mindset where you should check you have a -= call for the subscribed object when the subscribing object is about to run out of scope. Else you get random crashes, when you get events delivered to an object that should have been dead.

This is one of the reasons I don't like "event" and += in C#. It's a leaky abstraction, like you said.

There's WeakEventManager [0] but that's available only in "classic" dotnet framework (and in "new" dotnet but only if you're targeting Windows) since it lives in the WPF namespace. It can be used outside of it, but you still take a dependency on System.Windows.

There are some other bespoke solutions too.

There's an open issue on the dotnet repo to add a weak event manager to the standard libs [1]. It's very well worth reading through it, it also has links to the other bespoke solutions available.

[0] https://docs.microsoft.com/en-us/dotnet/api/system.windows.w...

[1] https://github.com/dotnet/runtime/issues/18645

Re: Reference count, don't garbage collect

#275

Post by bjourne »

Time to tout my own horn. I made a project comparing different types of garbage collectors (I still prefer the original terminology; both ref-counting and tracing garbage collection collects garbage, so they are both garbage collectors) a few years ago: https://github.com/bjourne/c-examples

Run ./waf configure build && ./build/tests/collectors/collectors and it will spit out benchmark results. On my machine (Phenom II X6 1090), they are as follows:

    Copying Collector                                8.9
    Reference Counting Collector                    21.9
    Cycle-collecting Reference Counting Collector   28.7
    Mark & Sweep Collector                          10.1
    Mark & Sweep (separate mark bits) Collector      9.6
    Optimized Copying Collector                      9.0
I.e for total runtime it is not even close; tracing gc smokes ref-counting out of the water. Other metrics such as number of pauses and maximum pause times may still tip the balance in favor of ref-counting, but those are much harder to measure. Though note the abysmal runtime of the cycle-collecting ref-counter. It suggests that cycle collection could introduce the exact same pause times ref-counting was supposed to eliminate. This is because in practice cycles are very difficult to track and collect efficiently.

In any case, it clearly is about trade-offs; claiming tracing gc always beats ref-counting gc or vice versa is naive.

Re: Reference count, don't garbage collect

#276

Post by bitcharmer »

smasher164 wrote: post #196
deterministic wrote: post #133

Earlier quoted context omitted.

Not my experience at all. I am maintaining a very high performance JIT compiler for a Haskell like programming language used in production at large enterprises around the world. So I am used to very carefully analyse performance. And reference counting is never the bottleneck. You might be right in theory but not in practice.

Not sure about the characteristics of your workload, but here's a talk where a group wrote device drivers in several high-level languages, and measured their performance: https://media.ccc.de/v/35c3-9670-safe_and_secure_drivers_in_... They found that the Swift version spent 76% of the time doing reference counting, even slower than Go, which spent 0.5% in the garbage collector.

Yeah, GP has no idea what they are talking about. They replied something similar on another thread without ever providing evidence for their claims. They even claimed their RC implementation in Haskell is faster than hand-crafted C++.

Gave me a chuckle.

Re: Reference count, don't garbage collect

#277

Post by pkolaczk »

al_mandi wrote: post #207
nemothekid wrote: post #90

It's my theory that Java, unintentionally, did a lot of damage to P&L research. I write a lot of Rust, and while the borrow checker is great, I've come to really admire the work that was put in the Go GC even if it's not as fast Java. There is a whole generation of programmers that have come to equate GC with Java's 10 second pauses or generics/typed variables with Java's implementation of them. Even the return to ty…

Java (the JVM) doesn't really have 10 second pauses anymore. G1GC and ZGC and Shenandoah have been a thing for a while now.

G1 can do 10 second pauses. I observed them many, many times. It tries not to, but there are no guarantees.

Re: Reference count, don't garbage collect

#278

Post by Jweb_Guru »

kaba0 wrote: post #218
_gabe_ wrote: post #200

Earlier quoted context omitted.

> trigger deallocation of a large object graph and it's not always clear by just looking at a code what will happen If you can't understand what's happening when an object gets freed, it may be a sign that your code is too tightly coupled and/or becoming spaghetti. I've found that the more graph-like my data structures become, the more inadvertent complexity I'm adding. That's the whole reason we talk about data norm…

Come on, object graphs are completely dynamic, noone can say where will “a variable go out of scope”, unless we literally have a hello world. Do you honestly claim that you know when deallocations happen in any codebase full of conditionals depending on outside effects (user input, network, etc)?

I mean... people program large developments in Rust with pretty minimal use of Arc. It's clearly possible to structure many programs this way (though they do not necessarily look like programs in other languages). It's important not to make extreme and definitive statements about what's realistic that are contradicted by a bunch of existing programs... in any case this has little bearing on the reference counting vs tracing GC performance thing. It also might be instructive to look at how Rust frameworks deal with your UI example: mostly, by keeping a vector of UI widgets and reusing the allocation over and over. Therefore, you shouldn't see a significant pause there (you could probably argue the pause comes when resizing the vector technically, but it is generally efficient enough that you're not going to notice it unless the vector is very very large).

Re: Reference count, don't garbage collect

#279

Post by pjmlp »

Animats wrote: post #250
viktorcode wrote: post #236

Earlier quoted context omitted.

Putting both under the same term is meaningless. Reference counting and Garbage Collection have very clear difference: when the referenced objects are destroyed (not deallocated). In RC it happens when the count reaches zero. In GC it happens some time later. That difference is crucial for having or not having deterministic performance in your program.

> In GC it happens some time later. Yes. In languages with destructors/finalizers called from the garbage collector, things can get very complicated. C# and Java have this problem. Go avoids it by having scope-based "defer" rather than destructors.

Java has scope based defer since version 7, while C# has it since version 4, with the improvement on version 8 to be syntactically like defer.

With a bit of generics and lambdas, they can be made to even be more defer like.

Re: Reference count, don't garbage collect

#280

Post by kaba0 »

Jweb_Guru wrote: post #278
kaba0 wrote: post #218

Earlier quoted context omitted.

Come on, object graphs are completely dynamic, noone can say where will “a variable go out of scope”, unless we literally have a hello world. Do you honestly claim that you know when deallocations happen in any codebase full of conditionals depending on outside effects (user input, network, etc)?

I mean... people program large developments in Rust with pretty minimal use of Arc. It's clearly possible to structure many programs this way (though they do not necessarily look like programs in other languages). It's important not to make extreme and definitive statements about what's realistic that are contradicted by a bunch of existing programs... in any case this has little bearing on the reference counting vs…

Statically adding code at the end of scope-leaves is different than knowing when the deallocation will happen.

The borrow checker doesn’t know when will the scope end, it only knows that however it happens upholds the invariants it cares about. You might call two entirely different code path inside a method and rust will only execute the dealloc logic at the end at a non-deterministic time. But maybe we just use different terminology here.

Post reply on HN