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

For Better Computing, Liberate CPUs from Garbage Collection

spectrum.ieee.org

Post reply on HN
Print view View original

431–440 of 460 posts

Re: For Better Computing, Liberate CPUs from Garbage Collection

#431

Post by nine_k »

norswap wrote: post #318
simias wrote: post #267

Earlier quoted context omitted.

I don't see your point. Of course sometimes the lifetime of an object is not tied to code scope but actually to something dynamic. Let's say for instance when you close a tab in your browser you expect the resources to be freed (ignoring caching to simplify the argument). Clearly somewhere in your code you have to explicitly handle tab closing and break the references to allow the GC to do its job. Why not free the r…

I mostly agree with your point on RAII. But I don't think OP was advocating RAII. The typical argument for GC is that it is less error-prone than even RAII. And I agree with that point. It's a trade-off on which you have to decide on. I think the tiny perf penalty is often worth it. You can still retain stale data under a GC, but real leaks (unreachable allocated memory) are precluded — which is usually considered (n…

You can of course introduce a space leak in a honest GC environment. Make a linked list, and keep adding items to it while keeping its head referenced. Of course you do it by mistake: you kept two references, the main and the auxiliary, and the main reference is duly gone.

This is why weak references were invented.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#432

Post by klodolph »

steveklabnik wrote: post #416
klodolph wrote: post #393

Earlier quoted context omitted.

True! And ARC in Rust suffers from the same problem (note that while ARC in Rust and ARC in Swift are the same thing, the "A" happens to stand for different words in each case).

They’re not the same thing; Swift is “automatic” and Rust is “atomic”; Swift’s ARC is implemented the same way as Rust’s Arc, but Rust’s is manual.

Hi! I think you may have repeated what I said in my comment, that the letter "a" stands for different things. Although they do the same thing: they are both atomic (in the sense of concurrency) and automatic (in the sense that you do not have to explicitly retain or release objects).

Re: For Better Computing, Liberate CPUs from Garbage Collection

#433

Post by sershe »

davedx wrote: post #82
arcticbull wrote: post #80

IMO garbage collection is the epitome of sunk cost fallacy. Thirty years of good research thrown at a bad idea. The reality is we as developers choose not to give languages enough context to accurately infer the lifetime of objects. Instead of doing so we develop borderline self-aware programs to guess when we're done with objects. It wastes time, it wastes space, it wastes energy. If we'd spent that time developing…

> It wastes time, it wastes space, it wastes energy. But all of these are much cheaper than developer labour and reputation damage caused by leaky/crashy software. The economics make sense. Anecdotally, I spent the first ~6 years of my career working with C++, and when I started using languages that did have GC, it made my job simpler and easier. I'm more productive and less stressed due to garbage collection. It's o…

Anecdotally for me, I spent more time in my first 0.5 years of Java tuning GC and debugging GC issues, than I spent chasing memory leaks in my previous 5 years of C++. The worst part is that you quickly learn to not introduce too many memory leaks, but as far as GC tuning goes the skill-set feels more like voodoo then science and is constantly obsoleted by GC code changes (or wholesale replacement).

I can see how this could be true in some cases and especially for throw-away code and when perf doesn't matter, but for anything at scale and/or with perf requirements, GC is terrible and wastes tons of developer time fighting it (debugging, tuning semi-opaque configs) and working around it (object pools, off-heap buffer managers, controlling object lifetime to avoid certain characteristics, controlling object size, etc.)

Re: For Better Computing, Liberate CPUs from Garbage Collection

#434

Post by steveklabnik »

klodolph wrote: post #432
steveklabnik wrote: post #416

Earlier quoted context omitted.

They’re not the same thing; Swift is “automatic” and Rust is “atomic”; Swift’s ARC is implemented the same way as Rust’s Arc, but Rust’s is manual.

Hi! I think you may have repeated what I said in my comment, that the letter "a" stands for different things. Although they do the same thing: they are both atomic (in the sense of concurrency) and automatic (in the sense that you do not have to explicitly retain or release objects).

That’s the thing: they’re not automatic in Rust. You have to explicitly retain. (Release is automatic though.)

Furthermore, in Swift it’s pervasive, and in Rust, it only happens for types that explicitly opt-in.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#435

Post by mafribe »

reitzensteinm wrote: post #128
mafribe wrote: post #115

Earlier quoted context omitted.

Au contraire , as memory, and hence workloads, get bigger, the cost of copying increases, and copying rather than sharing becomes ever more expensive. I just spoke with a physicist who told me that his current experiment produces 200 Gigabytes of data per second! Copying that amount of data around for immutability is inconceivable. Indeed the single biggest factor for performance for such workloads is minimising the…

Erlang style immutable reference counted shared memory is not at all state of the art. Persistent data structures are common and effective. I have implemented several myself, to store and update trees that don't fit in main memory. If you're updating one byte of your physicist's (say) 1 petabyte dataset, it requires ten memory allocations (log[branch factor] of the size of the dataset). If you're updating the whole t…

Are there high-performance matrix multiplication libraries, e.g. for fluid-dynamics simulations, that are implemented using persistent data structures?

Re: For Better Computing, Liberate CPUs from Garbage Collection

#436

Post by geocar »

apta wrote: post #376
StreamBright wrote: post #220

Earlier quoted context omitted.

It is weird, I do not feel restricted when I write non-GC code. Btw. you still need to pay attention with GCd languages no to leak references that cannot be GCd. Java has this sort of problems. Rust made it easy and simple to deal with memory in a non-malloc level while not having GC. Erlang on the other hand has a VM that makes GC much faster than in other languages. I can live with that because if you do it right i…

> still need to pay attention with GCd languages no to leak references that cannot be GCd. Java has this sort of problems. Unless you're doing weird things with class loaders, this is a non-issue. > Erlang on the other hand has a VM that makes GC much faster than in other languages What makes Erlang's VM make GC faster than other languages?

That's a very loaded question.

I don't think it's easy to point to one thing Erlang is doing and say that is why it's faster, partly because I think the way Erlang programmers are encouraged to write their programs also has an effect; The language itself may have a greater effect on its GC performance than the GC implementation itself.

As an example: In Erlang, we have function calls like F(X) but we also have message sends like F!X. Message sends get one type of memory treatment, while function calls get another one. The lifetime of objects you send via messaging is going to be different, and yet Java only has function(method) calls, so there's no way to hint this to Java. Maybe this information can be recovered with static/dynamic analysis, but in Erlang we have syntax to tell the VM what's going to happen.

If you want to learn more about Erlang's internals, I can recommend Joe's original paper on the subject:

http://citeseerx.ist.psu.edu/viewdoc/summary;jsessionid=0397...

since it describes a lot of the design that went into Erlang early, and:

http://www.it.uu.se/research/publications/lic/2005-001/

which while long, quite in-depth describes many of the sub-optimisations that can be realised on top of it.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#437

Post by fnord123 »

eru wrote: post #168
Patient0 wrote: post #136

Earlier quoted context omitted.

In the ~15 years I spent building software in C++ I don't recall a single time that I wished for garbage collection. By using RAII techniques, it was always possible (nay, easy!) to write code that cleaned up after itself automatically. I always found it easier to reason about and debug programs because I knew when something was supposed to be freed, and in which thread. The only time that use of simple reference cou…

C++ code is full of use after free problems. You can avoid those with garbage collection.

> You can avoid those with garbage collection.

Until you need to close a socket or file or unlock a mutex or respond to an async response handler.

$(cat /opt/propaganda/rust/raii-in-rust.txt)

Re: For Better Computing, Liberate CPUs from Garbage Collection

#438

Post by jokoon »

pkulak wrote: post #372
jokoon wrote: post #349

It reminds me of the days I was reading Knuth's quote "97% of the time premature optimisation blabla" every time someone was trying to make something faster. CPUs are not getting faster, yet it seems using tools that makes things run faster are somehow taboo. Wirth's law: Wirth's law is an adage on computer performance which states that software is getting slower more rapidly than hardware becomes faster. Why is java…

> frowns upon writing C because of arrays Do you mean horrifying security flaws?

You're right, but you cannot accuse the entire language of being insecure, ultimately it's the responsibility of the developer.

Also you can't always say we don't use C only for security reasons, as other languages also have their security issues. There are many modern ways to avoid those flaws. Like someone answered, it boils down to a matter of development cost.

I'm also quite skeptical when people always rise the objection of security when writing software. Security is not so simple, and so far it's its own specialty, and pretending that it's worth it to make things slower and that the security gain is actually there, is not really completely accurate.

Security is almost a post 9/11 paranoia knee jerk reaction.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#439

Post by pjmlp »

steveklabnik wrote: post #346
mcguire wrote: post #344

Earlier quoted context omitted.

? C++ and Objective C inherited C's memory model and thus don't have a good memory management option. Rust is explicitly a systems language, meaning stronger memory models are out of scope, and then inherited most of C++'s idioms. Other than those, what popular languages are specifically choosing reference counting as a primary GC method?

Swift.

Swift requires reference counting for compatibility with Objective-C code.

Apple could have gone the .NET way (RCW) to interface with COM reference counting, but that naturally would complicate the bindings to Objective-C runtime and existing libraries.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#440

Post by pjmlp »

stouset wrote: post #351
tempguy9999 wrote: post #135

Earlier quoted context omitted.

You say > but it was a false dichotomy: We can have memory safety without garbage collection. but then say > Automatic reference counting (ARC henceforth). Naive ARC is AFAIK very expensive as it causes a lot of updates at each pointer 'take' even if it's a read only (chasing pointers), trashing caches. Poss. even worse if multithreading is used as a memory barrier may have to be issued. Also it does not collect cycl…

> Naïve ARC is very expensive… So is/was garbage collection, and we’ve spent thirty years trying to squeeze every possible bit of performance out of it. Maybe it’s time to look at other approaches.

Even more so from reference counting, given that it was the very first kind of garbage collection algorithms.
Post reply on HN