Linus Torvalds on Garbage Collection (2002) • Hacker News Board

Re: Linus Torvalds on Garbage Collection (2002)

#181

Post by alextingle » Sat, Apr 23, 2011, 9:40 AM UTC

marshray wrote: post #121

Vlasta wrote: post #9

I like him mentioning the programmer's mindset associated with GC being a big danger. Some people consider GC a magic bullet and refuse to think about what's happening under the hood. I do not consider that a good habit.

It seems to be far easier (i.e., possible) to go from a manual-memory-management style of development to an automatic one than the other way around. I've known plenty of Java-CS-degree programmers who just never could get the hang of writing C/C++ code without leaking stuff (and not just memory).

This is a key point that I think lots of GC proponents gloss over. Memory is not the only resource that needs to be managed. Open file handles, sockets, user sessions, whatever... they all need to be managed in much the same way as memory.

Re: Linus Torvalds on Garbage Collection (2002)

#182

Post by jedbrown » Sat, Apr 23, 2011, 10:36 AM UTC

rayiner wrote: post #166

jedbrown wrote: post #148

Earlier quoted context omitted.

If you're not within 10% for these kernels, chances are that memory is being used differently. This gets to a further matter which I think is perhaps the greatest failure of current multi/many-core programming paradigms: assuming a flat memory model. Efficient parallel computation has much less to do with computation than with data movement. Recent and future architectures have deeply hierarchical memory systems so a…

> If you're not within 10% for these kernels, chances are that memory is being used differently More likely imperfect strictness analysis, etc. Haskell is a pure functional lazy language, after all. Getting within 65% of C's performance on a tight numeric kernel is heroic.

Different strictness analysis results in using memory differently. Note that some of Don's references are embedding a DSL that gives a high-level interface to very low-level code (e.g. CUDA) specific to this problem. They should have control over strictness.

Re: Linus Torvalds on Garbage Collection (2002)

#183

Post by rtaycher » Sat, Apr 23, 2011, 10:59 AM UTC

jrockway wrote: post #93

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).

C and Java apps with high contention don't scale well onto multiple cores, either. The key to speed is to not share state, which Python can do fine. It's called fork.

I thought the key was not managing mutable state. Sharing lots of immutable data can probably shave a lot of performance over ipc.

Re: Linus Torvalds on Garbage Collection (2002)

#184

Post by rtaycher » Sat, Apr 23, 2011, 11:08 AM UTC

pjkundert wrote: post #112

VeXocide wrote: post #74

Earlier quoted context omitted.

Absolutely not, http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1450.ht... explains why in section D. Implementation difficulty

Actually, yes. The boost::smart_ptr is highly effective. Prior to that existing, I wrote a similar ref-counting library that has been deployed to hundreds of remote sites, running high-reliability industrial control code. While complex, the ref-counting implementation gave me something that a GC system just can't deliver: Determinism. This system is running on a 300MHz embedded x86 hosts, in a solid-state industrial…

reference counting is slower* then other forms of gc. My guess why its fairly fast in c++ has a lot to do whith how much you can avoid it by allocating things on the stack(of course you can do escape anaylsis but most gc'd languages don't have explicit stack allocation of non basic types)

*with a lot of collaries

Re: Linus Torvalds on Garbage Collection (2002)

#185

Post by jedbrown » Sat, Apr 23, 2011, 11:33 AM UTC

rayiner wrote: post #165

jedbrown wrote: post #59

Earlier quoted context omitted.

Show me a memory-intensive kernel in which Haskell runs close to the performance model. Sparse and dense matrix kernels would be a good place to start. Our C code for sparse matrix-vector products and sparse triangular solves gets better than 90% of STREAM bandwidth (based on an assumption of optimal cache reuse, STREAM is about 85% of hardware peak). Dense matrix kernels should get better than 90% of FPU peak. Unlik…

You just described an ideal use-case for GC. You allocate a bunch of arrays at the outset, then sit there pounding on them with little to no allocation. A good GC won't cost you anything in this case, since it'll allocate large pointer-free arrays in a separate pool that doesn't get traced. Haskell isn't a good example, since it's a lazy functional language, but if something like Java isn't just as fast for your case…

I concede that my arguments were directed primarily at Haskell and actually more about data structure reuse than about GC. The threading model and task affinity is also relevant: if a compacting GC moves a hot data structure to a different memory bank, performance can be much slower. In principle, a runtime (with kernel support, libnuma may be sufficient on Linux) could set thread affinity, trace the page table for each (core,thread) pairs, and then have the compacting GC migrate threads and memory so that threads tended to use local memory. In principle, this could give better performance than most static distribution schemes, but this tracing costs something and to my knowledge, this sort of NUMA-aware GC is still a research topic.

Re: Linus Torvalds on Garbage Collection (2002)

#186

Post by caf » Sat, Apr 23, 2011, 12:06 PM UTC

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…

I tend to feel that the two often go together. After all, "the key to making a program fast is to make it do as little as possible".

Re: Linus Torvalds on Garbage Collection (2002)

#187

Post by z92 » Sat, Apr 23, 2011, 1:49 PM UTC

rdouble wrote: post #79

jpr wrote: post #73

Earlier quoted context omitted.

1+KLOCs a day of C? WTF?

Compared to other languages, C is pretty straightforward. You also have to write more of it to do less. I switched back to C after 12 years of using web scripting languages, and am surprised at how much more code I churn out per day.

Do you now use C for web apps? Like parsing GET, POST, DB, Cookies?

Re: Linus Torvalds on Garbage Collection (2002)

#188

Post by z92 » Sat, Apr 23, 2011, 1:53 PM UTC

FooBarWidget wrote: post #176

pjkundert wrote: post #112

Earlier quoted context omitted.

Actually, yes. The boost::smart_ptr is highly effective. Prior to that existing, I wrote a similar ref-counting library that has been deployed to hundreds of remote sites, running high-reliability industrial control code. While complex, the ref-counting implementation gave me something that a GC system just can't deliver: Determinism. This system is running on a 300MHz embedded x86 hosts, in a solid-state industrial…

Reference counting is not deterministic. Whenever a refcount is lowered to 0, you don't know how many subsequent references exist further up the chain that will also be lowered to 0. Lowering a refcount to 0 can result in an arbitrary amount of code to be executed depending on the references. If you mean that reference counting, on average, tends to result in fewer amounts of random/unpredictable pauses than most GCs…

I guess on that scale and probability, no code is deterministic.

Re: Linus Torvalds on Garbage Collection (2002)

#189

Post by kainosnoema » Sat, Apr 23, 2011, 2:22 PM UTC

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…

In my experience, it takes an incredible amount of effort and experience to solve a complex problem with simplicity and efficiency. It's well worth it, but there's definitely a cost, and not everyone is capable of it.

Re: Linus Torvalds on Garbage Collection (2002)

#190

Post by illumen » Sat, Apr 23, 2011, 3:00 PM UTC

barrkel wrote: post #46

Reference counting is GC; a poor form if it's the only thing you rely on, but it is automatic memory management all the same. Generational GC will frequently use the (L2/L3) cache size itself as its smallest generation, meaning it shouldn't suffer from the pathologies talked about by Linus here. What GC really gives you, though, is the freedom to write code in a functional and referentially transparent way. Writing f…

GC code runs differently depending on the code running around it. It causes the code to be non deterministic, and introduces a side effect.

I've written code in a reference counted language(python) which processes about a gigabyte of data per second from the network, with hard real time requirements - all on one machine with multiple cpus/cores. The code is fully unit tested, doc tested, and functionally tested. It's also short, runs on multiple platforms and has been maintained by other people than myself. My personal experience is that you can write highly efficient maintainable code with reference counting.

Reference counting manages memory automatically for you, but it also lets to manage memory manually when needed too. For many situations, it's the best of both worlds.