PyPy, the JIT-powered implementation
of the Python language built for speed, continues to press the pedal to
the metal and remains the easiest way to make Python fast and
convenient.
Both fast and easy
Aside from speed, PyPy's big appeal is its ease of use. Unlike Cython or Numba,
which require rewrites of Python apps, PyPy is a drop-in replacement
for CPython. Admins can accelerate existing software as is, and
developers can continue to develop in Python as they have always done.
PyPy has grown faster over time thanks to constant work on
its JITting compiler, with most of the performance improvements in the
latest build attributed to "internal refactoring and cleanups." Other
changes in PyPy include making the interpreter more useful to the
culture of tooling that already exists for Python -- like preliminary
support for vmprof, a profiler that reveals bottlenecks in Python code and is specifically designed to work with a JIT compiler like PyPy.
Calls to external C libraries, another speed-up technique
common in Python, also received a boost in PyPy via an upgrade to the
most recent version of Python's C foreign function interface system, which is used by libraries like the popular stats package Numpy. (Numpy itself also received a feature-support boost in PyPy 2.6.)
Other ways to rev up
Nuitka and
Pyston, two other recently minted Python-acceleration projects in the
works, stand in contrast to PyPy. Nuitka compiles Python to C++; Pyston, a project sponsored by Dropbox, uses JITting in conjunction with LLVM.
The former doesn't yet provide much of a speed boost -- around 2.58
times according to the last set of benchmarks -- and the latter is still
under heavy development. For the time being, PyPy remains the best
production-ready solution.
Where PyPy faces its biggest challenge is not in solving
technical problems, but in finding funding to keep development going.
Most of the work on the PyPy project is funded by donations, and efforts
to push forward with development for the Python 3.x, 64-bit Windows and
ARM versions of PyPy are stalled, according to the most recent blog
post.
Another donation-funded project, the Software Transactional Memory effort,
aims to do away with one of CPython's longest-standing performance
bugaboos, the Global Interpreter Lock (GIL). No easy solution exists,
and any solution developed for PyPy might not be rolled into CPython as
the bar for doing so is quite high: Python creator Guido van Rossum has said
the GIL will stay in CPython "until someone other than me goes through
the effort of removing it, and showing that its removal doesn't slow
down single-threaded Python code."
Comments
Post a Comment