Re: GIL-Removal Project Takes Another Step (Posting On Python-List Prohibited)

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

But Python’s present scheme for maintaining reference counts (the
“Global Interpeter Lock” or “GIL”) prevents Python code for taking full
advantage of multiple threads. Some are advocating switching to the
pure garbage-collection approach, but fortunately (I think) this is not
the plan that has been adopted by the Council.

I don't know the pro and anti GC arguments specifically in flight, so I
won't take a side here, but the idea that GC uses more memory seems
erroneous to me.  MicroPython uses GC and runs in machines with as
little as 16KB of ram (the BBC Micro v1).  I've used the CircuitPython
variant on chips with 32KB of ram and it is reasonably comfortable on
those.  I don't think CPython has ever run on machines that small.  GC
was invented in the 1950s for use in Lisp, on computers of that era that
were tiny compared with today's computers.

Classic GC adds one bit of overhead to each object, while reference
counting requires storing a refcount that is potentially large.  A
strict refcounting approach in a big computer might even need 64 bit
refcounts.  Also, the refcount has to be modified constantly.  I'm
amazed if that doesn't slow things down badly even in the single
threaded case.

Also, the "with" statement was added to Python partly to support
GC-based implementations, as some applications were relying on
refcounting to release resources when the object went out of scope, a
bad kludge.

Instead, they are going to use a technique known as “Biased Reference
Counting”.

That sounds ugly but I'm far away from it so dunno.

This seems to offer the best performance in tests so far.

They compared it to a serious GC and it won?  If yes, that is
interesting.

Seems some people are still smarting over the flak they got from the
Python 2 → 3 transition. “This is not Python 4,” they are saying. But
why not call it “Python 4”, as a warning over the likely compatibility
issues? Even if it probably won’t be quite as painful ...

We seem to be getting a Python 4 transition (i.e. breaking old code)
with each new release of Python 3, so this is just more of the same.

Anyway I'm glad effort is being made to remove the GIL.  If it were up
to me, I'd switch to BEAM or something like it as the underlying VM.