On Sat, Jan 17, 2009 at 7:57 PM, Paul Rubin <"http://phr.cx"@nospam.invalid> wrote: > alex23 <wuwe...@gmail.com> writes: >> Here's an article by Guido talking about the last attempt to remove >> the GIL and the performance issues that arose: >> >> "I'd welcome a set of patches into Py3k *only if* the performance for >> a single-threaded program (and for a multi-threaded but I/O-bound >> program) *does not decrease*." > > The performance decrease is an artifact of CPython's rather primitive > storage management (reference counts in every object). This is > pervasive and can't really be removed. But a new implementation > (e.g. PyPy) can and should have a real garbage collector that doesn't > suffer from such effects. > -- > http://mail.python.org/mailman/listinfo/python-list >
That's interesting, I hadn't heard the reference counting mechanism was related to the GIL. Is it just that you need to lock the reference count before mutating it if there's no GIL? Really, that shouldn't be the case. Reference counting can be done with a lock free algorithm. Garbage collection is definitely in vogue right now. However, people tend to treat it more like a religion than an algorithm. Garbage collection vs reference counting actually has some trade offs both ways. GC gets you some amortized performance gains, and some space gains because you don't need to hang on to a bunch of counts. However, GC also has the problem of having a very loose memory profile and poor interactive performance during compaction if the heap is large. In some cases this discussion becomes complicated with python because python has both reference counting and GC. -- http://mail.python.org/mailman/listinfo/python-list
