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

171–180 of 207 posts

Re: Linus Torvalds on Garbage Collection (2002)

#171

Post by glhaynes »

pohl wrote: post #115
microtherion wrote: post #96

Earlier quoted context omitted.

That's rarely a realistic option if you use any Cocoa library code. autorelease is a pretty fundamental aspect of the Cocoa design.

Wouldn't it be more accurate to say that it's not a realistic option for objects that come from or depend on Cocoa library code? Or would the mere act of using cocoa in one part of my application somehow prevent me from exploiting such an opportunity in another part of my application? My instinct says that, for example, a plain C library that used such techniques would not cease to function just by being linked into…

Your instinct is correct.

Re: Linus Torvalds on Garbage Collection (2002)

#172

Post by joe_the_user »

HenryR wrote: post #154
joe_the_user wrote: post #145

Earlier quoted context omitted.

Was my library about 50 times faster? Sure, I could parse 1,500+ XML-RPC requests/second. Did anybody actually benfit from this speed? Probably not. Then your (client's) problem wasn't reference counting but premature optimization. Are there situations where you'd like to have code run fifty times faster than native Python. You bet there are, lots and lots of them - for example, in a Unix-clone Kernel. Sorry if someh…

You're mixing up 'premature optimisation' and 'unnecessary optimisation'. The first is making code faster that isn't the bottleneck, or dominating performance factor. The second is making something faster than it needs to be. Profiling helps avoid the first, benchmarking helps avoid the second. Both require working (toy) systems, which is hard when you are evaluating which language to begin work in. Writing a library…

Seems like a rather small distinction. Unnecessary optimization is a natural result of premature optimization so I tended to assume that was what was happening. Unnecessary optimization can result from other things as well of course.

Regardless of this distinction, I think the same conclusions follow; the original problem had little to do with reference counting as such.

Re: Linus Torvalds on Garbage Collection (2002)

#173

Post by kragen »

ramchip wrote: post #158
kragen wrote: post #78

Earlier quoted context omitted.

One of the most expensive parts of the hardware is memory, and fast memory is a lot more expensive to produce than slower memory. So we have the choice between using the same (and thus slow) memory throughout the system, or combining different kinds of memory so that at software has at least the chance to run faster. This is a fundamental issue, and the only thing you can do is trying to find the optimal share for ea…

Isn't there a much simpler reason - that programs are generally single-threaded? I imagine it would take a lot of work to port basic tools like a web browser to such an architecture without it running much slower. A lot of applications do little parallelizable number-crunching, but a lot of branching and sequential operations. How could you make parsing XML or HTML fast on this? What about a text processor or a compi…

It's true, if Intel could make a single processor core that went eight times as fast on single-threaded code, they would do that instead of making eight-core chips, unless the cost difference was horrific. But they can't, so if you want your code to go faster, you have to find a way to parallelize it.

This started happening in earnest about 20 years ago in the supercomputer market, which is where the Tera was sold. About 10 years ago, it started happening in desktop CPUs (check out Herb Sutter's article about "the end of the free lunch") and now it's starting to happen in embedded microcontrollers, with the Parallax Propeller and the GreenArrays chips.

As it happens, the Tera didn't lose to faster single-threaded supercomputer CPUs. By the time the MTA came out, even the most stalwart defenders of the fast-single-threaded-performance approach, like the Cray SV1 and the NEC SX-5, had succumbed to the necessity of CPU parallelism. But the approach that was taking over the supercomputer market at the time was actually far more parallel, and far more difficult to program efficiently --- NUMA machines and then Beowulfs.

So that's why I don't think it was single-threaded programs that made the Tera fail in the supercomputer market.

The question of how to meaningfully parallelize XML and HTML parsing, compilation, text processing in general, and web browsers are very interesting indeed. It's not obvious how to do it, but it might turn out to be tractable. A group at Berkeley was doing some research on it in 2007 and 2008: http://www.eecs.berkeley.edu/~lmeyerov/projects/pbrowser/

Re: Linus Torvalds on Garbage Collection (2002)

#174

Post by cdavid »

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.

Sometimes you cannot easily not share state. The fact that you can use multiple processes to scale is not an interesting statement when comparing python to other languages because it is true for every language out there.

I think the GIL has made people in the python community too defensive: the GIL does not prevent from building scalable architectures in many cases, but it still sucks, and it would be better without. That's a limitation (and a tradeoff because it made development and integration with C easier). And there are scalable architectures based on threads (example: http://www.mailinator.com/tymaPaulMultithreaded.pdf) - "thread suck" has became a meme which slightly bothers me in general. Not a panacea, but a good solution when applicable.

Re: Linus Torvalds on Garbage Collection (2002)

#175

Post by FooBarWidget »

rayiner wrote: post #160
witten wrote: post #92

Earlier quoted context omitted.

That's a valid point, but you can do things to mitigate this, like splitting up your program into processes that have different dependencies. For instance, if you have a UI process and a core logic process, you won't need to import your giant UI library twice.

Or you could just use a language whose implementation doesn't blow.

And suffer from 5x slower development time. Yeah your deadline now has to be extended from 2012 to 2015 but at least the language is FAST and is technically excellent, right?

Re: Linus Torvalds on Garbage Collection (2002)

#176

Post by FooBarWidget »

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 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, then I agree.

Re: Linus Torvalds on Garbage Collection (2002)

#177

Post by InclinedPlane »

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?…

Context is always important. And there's no such thing as blanket advice that applies to every circumstance. Software development is a hugely varied endeavor, ranging over more orders of magnitude and more variety of application than almost any other industry. It stands to reason that most practices will vary rather considerably depending on context.

Linus writes from a systems perspective. He cares about every nanosecond and every byte. And that's appropriate and even laudable in the context of the linux kernel and core applications. But it's not always appropriate for every situation.

Re: Linus Torvalds on Garbage Collection (2002)

#178

Post by ramchip »

kragen wrote: post #173
ramchip wrote: post #158

Earlier quoted context omitted.

Isn't there a much simpler reason - that programs are generally single-threaded? I imagine it would take a lot of work to port basic tools like a web browser to such an architecture without it running much slower. A lot of applications do little parallelizable number-crunching, but a lot of branching and sequential operations. How could you make parsing XML or HTML fast on this? What about a text processor or a compi…

It's true, if Intel could make a single processor core that went eight times as fast on single-threaded code, they would do that instead of making eight-core chips, unless the cost difference was horrific. But they can't, so if you want your code to go faster, you have to find a way to parallelize it. This started happening in earnest about 20 years ago in the supercomputer market, which is where the Tera was sold. A…

My point was not aimed at the Tera specifically, but rather at this architecture as a solution to the memory problem in general. As you say, supercomputers have been using multi-threaded code for a long time now, so it's not a technical problem for this case, but it can be for the kind of applications 'regular users' may need.

Thanks for the references. I'm in embedded systems but I hadn't heard of the Parallax Propeller before, it's an interesting architecture.

Re: Linus Torvalds on Garbage Collection (2002)

#179

Post by kragen »

ramchip wrote: post #178
kragen wrote: post #173

Earlier quoted context omitted.

It's true, if Intel could make a single processor core that went eight times as fast on single-threaded code, they would do that instead of making eight-core chips, unless the cost difference was horrific. But they can't, so if you want your code to go faster, you have to find a way to parallelize it. This started happening in earnest about 20 years ago in the supercomputer market, which is where the Tera was sold. A…

My point was not aimed at the Tera specifically, but rather at this architecture as a solution to the memory problem in general. As you say, supercomputers have been using multi-threaded code for a long time now, so it's not a technical problem for this case, but it can be for the kind of applications 'regular users' may need. Thanks for the references. I'm in embedded systems but I hadn't heard of the Parallax Prope…

I suspect that the killer feature of Tera-like architectures for embedded systems could be their determinism. Embedded microcontrollers like the LPC2100 series are starting to get caches, branch prediction, and the like, and that makes me really nervous, because it's going to make worst-case timing very hard to reproduce in testing. (In a way, this has been the case since the introduction of interrupts in the 1960s, but I think it makes the problem much worse.)

If multithreaded or massively multicore processors were a viable alternative, you could get deterministic timings without sacrificing throughput. You could even do away with interrupts. The GreenArrays chip doesn't have interrupts at all; instead, its cores go into a low-power shutdown state whenever they're waiting on I/O.

But that's all pretty speculative.

Re: Linus Torvalds on Garbage Collection (2002)

#180

Post by alextingle »

albertzeyer wrote: post #65

When I read this, I immediately thought about std/boost::shared_ptr. This is a bit ironic since Linus hates C++ so much. shared_ptr is a really nice thing in C++. (For those who don't know: It is a ref-counting pointer with automatic freeing.) And its behavior is very deterministic. In many cases in complex C++ applications, you want to use that.

Or as we like to call it, std::shared_ptr
Post reply on HN