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

401–410 of 415 posts

Re: Reference count, don't garbage collect

#401

Post by naasking »

aaaaaaaaaaab wrote: post #299
naasking wrote: post #288

Earlier quoted context omitted.

> There are zero GC pauses. Unless you claim that a C++ alloc/feee call is “garbage collection”. Alloc/free can introduce arbitrary pauses last I checked, so yes, there are pauses. Any time doing book keeping for resources rather than running your code counts as GC time.

On any OS which is not hard realtime, there could be arbitrary pauses with any syscall. This is just nitpicking.

This is not nitpicking. The OP was implying they were using alloc/free in their GC. Those calls can be doing all sorts of book keeping behind the scenes, including cascading destructor calls which could free a chain of objects the size of live memory. Suffice it to say, that would pause.

Re: Reference count, don't garbage collect

#402

Post by elcritch »

mbrodersen wrote: post #384
elcritch wrote: post #210

Earlier quoted context omitted.

By requiring non-cyclic data structures or provide "weak" references. It's actually pretty easy to write most code without cycles. I program a lot in Nim and generally compile lots of programs with ARC and no cycle collector without issue.

Yep. The language doesnt allow data cycles. Nobody ever complained about that or even noticed it.

Not sure what you mean but Nim allows data cycles.

I just prefer to write cycle free code when I can and turn off the cycle collector. Though Nim’s cycle collector performs well and does some tricks using the RCs.

Re: Reference count, don't garbage collect

#403

Post by wizofaus »

mbrodersen wrote: post #395
wizofaus wrote: post #390

Earlier quoted context omitted.

That seems a little hard to believe. I can't think of many complex pieces of software I've worked on that didn't have such cycles (e.g. any sort of tree structure where parents need to know about children and children need to know about parents - how does Nim handle that?)

You typically use a weak pointer from child to parent in those situations. So there are no ownership cycles. Languages without garbage collectors (C/C++) pretty much require you to not have ownership cycles or your code will crash during cleanup. Unless you add specific code to detect it and stop it from happening. So I assume you mostly work in GC languages and not C/C++?

We were talking about Nim, which is language I know next to nothing about (but very familiar with C/C++, Swift - which has weak pointers, as well as GC languages like JavaScript/Java/C# etc.)

Re: Reference count, don't garbage collect

#404

Post by badpun »

coding123 wrote: post #171
mandevil wrote: post #112

Earlier quoted context omitted.

Not OP, but someone who has gotten paid to write Java for several years. I would say that isn't that Java's semantics are that verbose, it's that the way Java is traditionally written, with every line actually 3 lines on your screen of public function makeItalicTextBox(String actualTextIWantToBeItalic) { ItalicTextBox itb = italicTextBoxFactoryGenerator.GenerateFactory().buildItalicTextBox(actualTextIWantToBeItalic);…

This is one of the reasons I left Java after 30 years. For those that wonder my day to day is now python and typescript.

Java is 27 years old though?

Re: Reference count, don't garbage collect

#405

Post by elcritch »

wizofaus wrote: post #390
mbrodersen wrote: post #384

Earlier quoted context omitted.

Yep. The language doesnt allow data cycles. Nobody ever complained about that or even noticed it.

That seems a little hard to believe. I can't think of many complex pieces of software I've worked on that didn't have such cycles (e.g. any sort of tree structure where parents need to know about children and children need to know about parents - how does Nim handle that?)

Nim does allow cycles and the new GC is non-atomic RC + cycle collector.

Though I’ve been hacking on a UI framework written in Nim. Its ui nodes form a tree structure that only tracks parent => child. When it needs the parent info it makes a stack of parents during processing.

Essentially it moves the cycle collector / GC work to extra work during processing. But it’s cheaper since you’re already accessing the memory.

Re: Reference count, don't garbage collect

#406

Post by pclmulqdq »

UncleEntity wrote: post #284
pclmulqdq wrote: post #147

Earlier quoted context omitted.

The global optimization step is often what people commonly refer to as "garbage collection." Putting it inside a framework to RC as few times as possible is pretty cool. However, I doubt the efficacy of your C++ experts: most of the people I know who write C++ are actually really bad at optimizing code. They mostly use it for legacy reasons. If you get a team of experienced (and expensive) systems programmers, you wi…

> However, I doubt the efficacy of your C++ experts: most of the people I know who write C++ are actually really bad at optimizing code. Which is a very good reason to develop an optimized GC algorithm, the domain experts can crank out code without having to optimize every single memory (de)allocation which sounds like a waste of their time. It’s funny, people don’t usually doubt that a modern compiler can do a bette…

Personally, I think non-GC languages are very much overused. If you are writing business logic, and not counting cycles (even worse - if you are never planning to count cycles), you should probably not use C++ or Rust.

However, a GC is a lot slower than manual memory management, which contrasts with the fact that most compiler activities are actually pretty low in overhead (now - it didn't used to be this way). Really, the only cost overhead left is the abstraction mismatch, and that is not too bad, when you compare to how bad humans are at writing assembly.

That said, this case looks like one where the C++ experts spent very little time optimizing (mostly writing business logic), and probably made a very poor choice of tools.

Re: Reference count, don't garbage collect

#407

Post by mbrodersen »

GrumpySloth wrote: post #396
mbrodersen wrote: post #373

Earlier quoted context omitted.

The compiler uses arrays not linked lists. One of the big mistakes that other functional compilers make (IMHO) is that they use linked lists. It is a huge performance problem. There is a reason why high-performance software written in C++ and C always use arrays and not linked lists. Memory access patterns is the #1 thing to optimise for on modern CPUs.

So, as I understand it, you avoid pauses by avoiding data structures with long chains of pointers. The same will work equally well in a language with a GC. It's also not the case that reference-counting itself doesn't result in pauses itself, but that the user is responsible for using such data structures that they do not result in pauses. Which I think is the only way when you care about performance, no matter wheth…

So according to your logic no pause GC is impossible? In that case my claim is that it works as fast as what an expert in C/C++ optimisations would hand craft the compiled code to do by carefully minimising allocs/frees. This is what AAA games do to minimise stuttering. You can achieve the same with GC languages like Java. However you then have to manually keep a pool of objects and manually “alloc/free” objects from that pool. That is what games written in GC languages do to avoid random GC pauses.

Re: Reference count, don't garbage collect

#408

Post by tomsmeding »

mbrodersen wrote: post #370
tomsmeding wrote: post #269

Earlier quoted context omitted.

Haskell specifically is a poor choice of language here, because it creates cycles like the pest. (This is because it uses lazy evaluation, and programming patterns (design patterns?) using lazy evaluation tend to use cyclical references. Strict FP languages might support your point better, but then Ocaml again doesn't work because it mutates like the pest.) Furthermore it also allocates like the pest: busy Haskell pr…

It is a Haskell inspired language but not Haskell. The syntax is similar but it is eagerly evaluated and has no IO and no data cycles. It is used 100% for evaluating complex optimisation and business rules within a client application. The language was carefully crafted to maximise rules writer productivity and execution performance.

Ah, I was just responding to my parent, committing the sin to not remember what they are replying to.

Interesting; with purity and eager evaluation, and presumably no mutually recursive bindings either, you should indeed get absence of cycles. I do wonder: does absence of mutually recursive bindings come back to bite you at some point? Or does the need for that just not arise in your domain?

Is there stuff that you feel is awkward to express in your language that would be fine in Haskell proper?

Re: Reference count, don't garbage collect

#409

Post by [deleted] »

arcticbull wrote: post #67
klodolph wrote: post #65

Earlier quoted context omitted.

> RC may turn reads into writes, but of course, GC ends up having to go through literally every piece of memory ever from time to time. Depends on the GC algorithm used. Various GC algorithms only trace reachable objects, not unreachable ones. Reference counting does the opposite, more or less. When you deallocate something, it's tracing unreachable objects. One of the problems with this is that reference counting to…

> When I hear rhetoric like this, all I think is, "Oh, this person really hates GC, and thinks everyone else should hate GC." Yeah, I think it's an inelegant, brute-force solution to a language problem - and that we continue to throw good money after bad improving it. We should be investing in removing the need for GC through smarter compilers and through languages that allow us to better express our intent - and our…

[deleted]

Re: Reference count, don't garbage collect

#410

Post by GrumpySloth »

mbrodersen wrote: post #407
GrumpySloth wrote: post #396

Earlier quoted context omitted.

So, as I understand it, you avoid pauses by avoiding data structures with long chains of pointers. The same will work equally well in a language with a GC. It's also not the case that reference-counting itself doesn't result in pauses itself, but that the user is responsible for using such data structures that they do not result in pauses. Which I think is the only way when you care about performance, no matter wheth…

So according to your logic no pause GC is impossible? In that case my claim is that it works as fast as what an expert in C/C++ optimisations would hand craft the compiled code to do by carefully minimising allocs/frees. This is what AAA games do to minimise stuttering. You can achieve the same with GC languages like Java. However you then have to manually keep a pool of objects and manually “alloc/free” objects from…

No-pause GC is possible, when we're talking about concurrent GCs, but it also shouldn't be mistaken for a "no-overhead GC". And reference-counting, as long as the actual reference counting isn't done in a separate thread as well, instead of blocking in a destructor, which triggers other destructors, is not a no-pause GC. It's true that application developer can avoid pauses even then, but that's a different claim.

From what I've been told, C++ games do another thing and just use arena allocators, which make allocations cheap (just an integer addition, provided you know a reasonable upper bound on the size of an arena, and if you don't, you may reserve a large piece of virtual memory, and commit it later in reasonably small, but also not too large chunks) and free-s even cheaper (either reset the integer, so that the arena can be reused, or a single syscall to unmap the whole arena in one go). That's a different strategy than making a lot of little allocs and frees, and then trying to minimize them by reusing objects, which is also quite hairy.

Post reply on HN