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

Linus Torvalds on Garbage Collection (2002)

gcc.gnu.org

Post reply on HN
Print view View original

101–110 of 207 posts

Re: Linus Torvalds on Garbage Collection (2002)

#101

Post by joeyespo »

I think this is another case of everybody thinks about garbage collection the wrong way: http://blogs.msdn.com/b/oldnewthing/archive/2010/08/09/10047...

From the article: "Garbage collection is simulating a computer with an infinite amount of memory. The rest is mechanism."

Whether or not it's reference counting or generational, the goal is still to simulate infinite memory. That way, you can focus on the high-level problems instead of the technical memory-related details. So it's not necessarily a bad mindset to have.

Re: Linus Torvalds on Garbage Collection (2002)

#102

Post by chc »

kragen wrote: post #63
cdavid wrote: post #56

Earlier quoted context omitted.

And it is one of the reason why python is slow and difficult to scale on multiple cores (the main difficulty by far of removing the GIL is reference counting).

Scaling Python on multiple cores is easy: you just run multiple Python processes, each with its own per-core GIL. You are correct, though, that ref-counting overhead is one of the main reasons Python is slow.

This is a bit like saying, "Of course C has full type safety. Just use a Haskell implementation written in C." Both your statement and his are technically accurate, but yours is on a subtly different topic.

Re: Linus Torvalds on Garbage Collection (2002)

#103

Post by cpeterso »

BenoitEssiambre wrote: post #29
jasongullickson wrote: post #7

What he's advocating sounds a lot like how things work in the iOS world, in my experience.

And thus the insanely smooth user experience on iOS. As an Android developer, this is _the one thing_ I feel makes it difficult to have a polished user experience on Android compared to iOS. If you think long and hard about each place you call 'new' in java Android apps, it is possible to get a smooth interface. However, the language doesn't encourage it by default like on iOS and you have to put time into it you usu…

And that Android's GUI did not use GPU hardware acceleration until Honeycomb. The iOS GUI uses hardware acceleration extensively (which is admittedly probably easier when you control the iOS devices' hardware design).

https://code.google.com/p/android/issues/detail?id=6914

Re: Linus Torvalds on Garbage Collection (2002)

#104

Post by Jach »

loup-vaillant wrote: post #35

So. Programs that use Garbage Collection tend to be slow. Cause: Hardware don't like it. Solution: fix the hardware? Seriously, I'm afraid we're stuck in a local optimum here. It is as if machines are optimized for the two dominant C/C++ compilers out there, and we have then to optimize our program against that, closing the loop. Shouldn't compilers and hardware be designed hand in hand?

You might enjoy reading this: http://www.thocp.net/biographies/papers/backus_turingaward_l... (I've been casually trying to implement an FFP Machine on an FPGA.)

Re: Linus Torvalds on Garbage Collection (2002)

#105

Post by __david__ »

I like the way the D language approached this. It's garbage collected but it also has a "delete" function/operator. That way you can use garbage collection if you'd like, or you can manually free memory when you think it's worth it.

That seems like a reasonable compromise and I'm surprised that more languages don't do it.

Re: Linus Torvalds on Garbage Collection (2002)

#106

Post by ekidd »

yid wrote: post #58
ekidd wrote: post #37

Shortly before Linus wrote this article in 2002, I wrote an XML-RPC library in C that used reference counting. By the time I was done, I'd written 7,000+ lines of extremely paranoid C code, and probably eliminated all the memory leaks. The project cost my client ~$5K. The standard Python xmlrpc library was less than 800 lines of code, and it was probably written in a day or two. Was my library about 50 times faster?…

Please don't take this personally, but the fact that your code was N thousand lines doesn't mean the task is inherently an N-thousand line task. Also, undertaking anything with XML in C is brave, kudos.

If you know of any way to make the code shorter and more concise, please let me know. I'm always looking for ways to improve.

https://gist.github.com/937200 (two sample files, totaling slightly less than half the project)

Posting 10-year-old code to HN is always a little embarrassing, but please feel free to be brutal. I'll live. :-) I was definitely way too in love with the preprocessor back then.

Here's the corresponding Python code, from shortly after it hit 1,000 lines in late 2001:

http://hg.python.org/cpython-fullhistory/file/7b2d701ec404/L...

I like the Python code rather better, if only because there's so much less explicit memory management. The actual ideas stand out clearly, and there's just so much less code to read. In most cases, I'd happily sacrifice the performance.

Re: Linus Torvalds on Garbage Collection (2002)

#107

Post by chc »

gruseom wrote: post #87
jfr wrote: post #25

> A GC system with explicitly visible reference counts (and immediate freeing) with language support to make it easier to get the refcounts right [...] To be a little pedantic on the subject, such a system (reference counting and immediate freeing) is a form of automatic memory management, but it is not GC in any way. Garbage collection implies that the system leaves garbage around, which needs to be collected in som…

I like simplicity. Simplicity tends to perform well, and being simple also means it has little space for problems. Amen. I saw an old interview with Chuck Moore a while ago in which he said: I like simplicity and efficiency. That struck me. How often do people put those two things together? We're conditioned to think of them as a tradeoff. But if you can have both, shouldn't we be trying hard for that? Which raises a…

It's because "simple" can be a measure of different things. C is a pretty simple and straightforward language, but it takes 10 times as much code to do anything, which could be said to be quite a bit more complex.

Re: Linus Torvalds on Garbage Collection (2002)

#109

Post by ekidd »

jeffdavis wrote: post #97
DanielRibeiro wrote: post #57

Earlier quoted context omitted.

I Guess Linus also made another suggestion which he didn't pursue on this paragraph: Generational garabage collectors tend to never re-use hot objects, and often do the copying between generations making things even worse on the cache The suggestion? Just reuse hot objects. Note, this post is from 2002. Garbage collectors have improved a lot over the last 9 years. Don't evaluate new technology with such old arguments…

Linus was quite specific about his problems with GCs. Just saying that "garbage collectors have improved" without specifics, and calling his arguments "old" doesn't add much information. Can you tell us how they have improved in ways that address Linus's specific concerns? And explain how a generational garbage collector can effectively re-use freshly freed objects before they leave the cache? Which 2011 generational…

Reusing hot memory is a pretty ancient GC technique, though the details have varied over the decades.

You can Google "nursery generation" for some examples:

http://www.google.com/search?q=gc+nursery+generation

The original theory was that most objects in a functional language are extremely short-lived, and you want to reclaim them quickly. But if you GC your nursery generation after every few kB of allocations, you'll also keep the memory in L1 and L2 cache.

The ideal size of a nursery generation (and the value of reusing hot memory) should be measured empirically.

Of course, most popular scripting language GCs are non-copying, reference-counting collectors, which means they ignore techniques that were well-understood back in the 80s. However, this has not been a barrier to the adoption of Python, Ruby, etc., because the business value of high-performance code is often minimal.

Re: Linus Torvalds on Garbage Collection (2002)

#110

Post by ori_b »

jeffdavis wrote: post #97
DanielRibeiro wrote: post #57

Earlier quoted context omitted.

I Guess Linus also made another suggestion which he didn't pursue on this paragraph: Generational garabage collectors tend to never re-use hot objects, and often do the copying between generations making things even worse on the cache The suggestion? Just reuse hot objects. Note, this post is from 2002. Garbage collectors have improved a lot over the last 9 years. Don't evaluate new technology with such old arguments…

Linus was quite specific about his problems with GCs. Just saying that "garbage collectors have improved" without specifics, and calling his arguments "old" doesn't add much information. Can you tell us how they have improved in ways that address Linus's specific concerns? And explain how a generational garbage collector can effectively re-use freshly freed objects before they leave the cache? Which 2011 generational…

You can bypass the GC entirely, and keep the objects that really should be in cache live, and just reuse them. Not a pretty solution, but it's doable.
Post reply on HN