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

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

In other words, it’s not “completely” false if you have to do something to
make it false.

No you don't have to do anything, it is false by default.  In Java the
default GC interval is relatively small, and to make it bigger you use
the -XMx option iirc.

Remember we are talking about GIL removal to get speedups on multicore
processors.  I expect any such processors these days

But that GC process creates its own overhead

Refcounting has overhead too! 

not to mention the latency when there isn’t quite enough memory for an
allocation and you have to wait until the next GC run to proceed.

If you are GC'ing every N allocations and you run out of free space
before you've done those N, you increase the region size by asking for
more memory from the system.  If the system is out of memory, it is
out of memory and you need a bigger computer or some other change.
You don't "wait for the next GC run" as if it were a periodic daemon.

With reference counting, most objects are immediately freed as soon as
they are discarded--no need to wait for the next GC run.

In other words you effectively GC every time an object is freed instead
of having a tuneable parameter that you can optimize.  And of course you
don't get freedom from pauses either.  If you allocate a million element
list in Python, then drop the last reference to the list, you have to
decrement the refcounts of each of the million elements, however long
that takes.  Plus if that decrements most or all of them to zero, you
have to free them one by one.  With a copying-style GC, you never have
to visit those elements or free them individually.

Look, widely used GC'd languages include Java, SBCL and other comparable
Lisp systems, GHC, OCaml, Erlang, .NET (C# and F#), Golang, current
incarnations of Javascript, and others.  All of them beat the pants off
of CPython in performance.  If you're claiming CPython's refcounting
system somehow outperforms the above mentioned GC's, I'd be interested
in seeing some benchmarks.  There may be some trade-offs in CPython that
make its refcount system still advantageous for some things, but
performance is unlikely to be one.