[Python-checkins] peps: PEP 510: rationale for static optimize vs JIT compiler

[victor.stinner]

https://hg.python.org/peps/rev/b463c740990c
changeset:   6155:b463c740990c
user:        Victor Stinner <victor.stinner at gmail.com>
date:        Sun Jan 10 14:58:17 2016 +0100
summary:
  PEP 510: rationale for static optimize vs JIT compiler

files:
  pep-0510.txt |  62 ++++++++++++++++++++++++++++++++++++++++
  1 files changed, 62 insertions(+), 0 deletions(-)


diff --git a/pep-0510.txt b/pep-0510.txt
--- a/pep-0510.txt
+++ b/pep-0510.txt
@@ -20,6 +20,9 @@
 Rationale
 =========
 
+Python semantic
+---------------
+
 Python is hard to optimize because almost everything is mutable: builtin
 functions, function code, global variables, local variables, ... can be
 modified at runtime. Implement optimizations respecting the Python
@@ -34,6 +37,65 @@
 Writing an optimizer is out of the scope of this PEP.
 
 
+Why not a JIT compiler?
+-----------------------
+
+There are multiple JIT compilers for Python actively developed:
+
+* `PyPy <http://pypy.org/>`_
+* `Pyston <https://github.com/dropbox/pyston>`_
+* `Numba <http://numba.pydata.org/>`_
+* `Pyjion <https://github.com/microsoft/pyjion>`_
+
+Numba is specific to numerical computation.  Pyston and Pyjion are still
+young.  PyPy is the most complete Python interpreter, it is much faster
+than CPython and has a very good compatibility with CPython (it respects
+the Python semantic). There are still issues with Python JIT compilers
+which avoid them to be widely used instead of CPython.
+
+Many popular libraries like numpy, PyGTK, PyQt, PySide and wxPython are
+implemented in C or C++ and use the Python C API. To have a small memory
+footprint and better performances, Python JIT compilers do not use
+reference counting to use a faster garbage collector, do not use C
+structures of CPython objects and manage memory allocations differently.
+PyPy has a ``cpyext`` module which emulates the Python C API but it has
+worse performances than CPython and does not support the full Python C
+API.
+
+New features are first developped in CPython. In january 2016, the
+latest CPython stable version is 3.5, whereas PyPy only supports Python
+2.7 and 3.2, and Pyston only supports Python 2.7.
+
+Even if PyPy has a very good compatibility with Python, some modules are
+still not compatible with PyPy: see `PyPy Compatibility Wiki
+<https://bitbucket.org/pypy/compatibility/wiki/Home>`_. The incomplete
+support of the the Python C API is part of this problem. There are also
+subtle differences between PyPy and CPython like reference counting:
+object destructors are always called in PyPy, but can be called "later"
+than in CPython. Using context managers helps to control when resources
+are released.
+
+Even if PyPy is much faster than CPython in a wide range of benchmarks,
+some users still report worse performances than CPython on some specific
+use cases or unstable performances.
+
+When Python is used as a scripting program for programs running less
+than 1 minute, JIT compilers can be slower because their startup time is
+higher and the JIT compiler takes time to optimize the code. For
+example, most Mercurial commands take a few seconds.
+
+Numba now supports ahead of time compilation, but it requires decorator
+to specify arguments types and it only supports numerical types.
+
+CPython 3.5 has almost no optimization: the peephole optimizer only
+implements basic optimizations. A static compiler is a compromise
+between CPython 3.5 and PyPy.
+
+.. note::
+   There was also the Unladen Swallow project, but it was abandonned in
+   2011.
+
+
 Example
 =======
 

-- 
Repository URL: https://hg.python.org/peps