4 ms·
It seems to me that the option of going with a tracing garbage collector is preferable. Removing the GIL will require a lot of changes anyway, and it may be bet
by andreasvc 10y ago
It seems to me that the option of going with a tracing garbage collector is preferable. Removing the GIL will require a lot of changes anyway, and it may be better to go all they way so as to preserve performance. It would affect the C API and extensions modules would have to be reworked for this, but on the other hand you avoid all the issues with reference counting. If extension modules rely on code generation, such as Cython, a move to a radically different C API might be less painful than expected.
From what I know, most current managed languages are using GC, not reference counting, so perhaps it's an inherently better approach.
- Animats 10y agoMost of the Python implementations other than CPython use GC rather than reference counting. PyPy does. Iron Python did.[1] There is a version of PyPy without a GIL[2], but it runs much slower on ordinary code and is still under development. The developers are looking for financial support.[3] The approach is to identify large blocks of code as transactions, and run them in parallel. If they try to access the same data, one transaction fails and is backed out. It's like database rollback. But you have to write your code like this: from transaction import TransactionQueue tr = TransactionQueue() for key, value in bigdict.items(): tr.add(func, key, value) tr.run() [1] http://doc.pypy.org/en/latest/cpython_differences.html http://doc.pypy.org/en/latest/cpython_differences.html [2] http://doc.pypy.org/en/latest/stm.html http://doc.pypy.org/en/latest/stm.html [3] http://pypy.org/tmdonate2.html http://pypy.org/tmdonate2.html