what's the point of rpython?

[Brendan Miller]

On Sat, Jan 17, 2009 at 7:57 PM, Paul Rubin
<"http://phr.cx"@nospam.invalid> wrote:
> alex23 <wuwei23 at 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.