[Python-Dev] A new JIT compiler for a faster CPython? (original) (raw)
Amaury Forgeot d'Arc amauryfa at gmail.com
Wed Jul 18 00:49:18 CEST 2012
- Previous message: [Python-Dev] A new JIT compiler for a faster CPython?
- Next message: [Python-Dev] A new JIT compiler for a faster CPython?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
2012/7/18 Nick Coghlan <ncoghlan at gmail.com>:
On the cpyext front, it would be rather helpful if developers interested in a high speed Python interpreter with good C extension compatibility worked with Dave Malcolm on his static analyser for Python C extensions. One of the reasons cpyext has trouble is that many refcounting bugs in extensions aren't fatal on CPython’s due to additional internal references - a refcount of 1 when it should be 2 is survivable in a way that 0 vs 1 is not.
It's not only about bugs. Even when reference counts are correctly managed, cpyext is slow:
each time an object crosses the C|pypy boundary, there is a dict lookup (!)
each time a new object is passed or returned to C, a PyObject structure must be allocated (and sometime much more, specially for strings and types). Py_DECREF will of course free the PyObject, so next time will allocate the object again.
borrowed references are a nightmare.
Get rid of that drudgery from hacking on cpyext and it becomes significantly easier to expand the number of extensions that will work across multiple implementations of the API.
There are also some extension modules that play tricky games with the API; PyQt for example uses metaclasses with a custom tp_alloc slot, to have access to the PyTypeObject structure during the construction of the type... The Python C API is quite complete, but some use cases are still poorly supported.
-- Amaury Forgeot d'Arc
- Previous message: [Python-Dev] A new JIT compiler for a faster CPython?
- Next message: [Python-Dev] A new JIT compiler for a faster CPython?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]