[Python-ideas] Add specialized bytecode with guards to functions
Victor Stinner
victor.stinner at gmail.com
Wed Oct 21 18:35:38 CEST 2015
On 21 October 2015 at 17:48, Chris Angelico <rosuav at gmail.com> wrote:
> * Compare against PyPy.
As written in my email, don't expect better performances than PyPy.
PyPy must remain the fatest implementation of Python ;-)
The final goal is to see real speedup on non-trivial applications like
Django Mercurial, or OpenStack.
2015-10-21 18:11 GMT+02:00 Nick Coghlan <ncoghlan at gmail.com>:
> * Full CPython C API compatibility
FYI the FAT mode uses fat.verdict and fat.SpecializedFunction types
which are subtypes of dict and types.FunctionTypes, so you keep a full
compatibility of the C API.
I noticed one issue with the C API:
#define PyFunction_Check(op) (Py_TYPE(op) == &PyFunction_Type)
This test fails with fat.SpecializedFunction. It means that C
extensions must be recompiled to with the FAT mode. I modified the
macro to:
#define PyFunction_Check(op) \
(Py_TYPE(op) == &PyFunction_Type \
|| PyType_IsSubtype(Py_TYPE(op), &PyFunction_Type))
> * Reliance on ahead of time compilation means it works for command
> line scripts, not just long running server processes that allow the
> PyPy tracing JIT to work its magic
Yes, a I wrote in my email, CPython still beats PyPy for fast command
line scripts like many Mercurial commands. PyPy JIT takes time to
warmup. (Hum, in fact I only read time, I didn't check, sorry.)
So yes, I also expect faster performances with static compilation on
such use case.
> An existing example of this kind of guard-based optimisation exists in
> the ABC machinery - we globally version the ABC registration graph in
> order to automatically invalidate caches when a new explicit
> registration is added.
Hum, this is a common cache. CPython has many similar caches, like
cache for methods on types, but it's not guard for function calls. I
would like to know if someone else tried to write specialized
functions with guards in other scripting languages (or even Python?).
Victor
More information about the Python-ideas
mailing list