Is PyPy Ready for Production
•
2 likes•3,886 views
PyPy is an implementation of the Python language written in RPython, a restricted subset of Python. It includes a just-in-time compiler that can provide significant performance improvements over CPython for certain workloads. The author benchmarked several of their workflows and found that PyPy was 2-4x faster for some tasks like CSV to XML conversion, but up to 4x slower for others like simple CSV parsing. Overall, PyPy satisfies most criteria for production readiness and supports the key Python modules used by the author's projects, making it a viable alternative to CPython for improving performance.
Recommended
More Related Content
What's hot
What's hot (19)
Similar to Is PyPy Ready for Production
Similar to Is PyPy Ready for Production (20)
More from Mark Rees
Recently uploaded
Recently uploaded (20)
Is PyPy Ready for Production
- 1. is it ready for production? Mark Rees Group CTO Censof Holdings Berhad
- 2. pypy & me not affiliated with pypy team have followed it‟s development since 2004 use cpython and jython at work used ironpython for small projects the question: would pypy improve performance of some of our workloads? i am a manager, who still is wants to be a programmer, so i did the analysis
- 3. pypy what is pypy? - RPython translation toolchain, a framework for generating dynamic programming language implementations - a implementation of Python in Python using the framework history - first sprint 2003, EU project from 2004 – 2007 - open source project from 2007 https://bitbucket.org/pypy - pypy 1.4 first release suitable for “production” 12/2010
- 4. pypy want to know more about pypy - http://pypy.org/ - david beazley pycon 2012 keynote http://goo.gl/5PXFQ - how the pypy jit works http://goo.gl/dKgFp - why pypy by example http://goo.gl/vpQyJ
- 5. production ready – a definition http://programmers.stackexchange.com/questions/61726/define-production-ready it runs it satisfies the project requirements its design was well thought out it's stable it's maintainable it's scalable it's documented it works with the python modules we use it is as fast or faster than cpython
- 6. pypy – does it run? of course, it runs See http://pypy.readthedocs.org/en/latest/cpython_differences.html for differences between PyPy and CPython
- 7. pypy – other production criteria does it satisfy the project requirements - yes is it‟s design was well thought out - I would assume so is it stable - yes is it maintainable - 7 out of 10 is it scalable - stackless & greenlets built in is it documented - cpython docs for functionality, rpython toolchain 8 out of 10
- 8. pypy – does it work with the modules we use standard library modules supported: __builtin__, __pypy__, _ast, _bisect, _codecs, _collections, _ffi, _hashlib, _io, _locale, _lsprof, _md5, _minimal_curses, _multiprocessing, _random, _rawffi, _sha, _socket, _sre, _ssl, _warnings, _weakref, _winreg, array, binascii, bz2, cStringIO, clr, cmath, cpyext, crypt, errno, exceptions, fcntl, gc, imp, itertools, marshal, math, mmap, operator, oracle, parser, posix, pyexpat, select, signal, struct, symbol, sys, termios, thread, time, token, unicodedata, zipimport, zlib these modules are supported but written in python: cPickle, _csv, ctypes, datetime, dbm, _functools, grp, pwd, readline, resource, sqlite3, syslog, tputil many python libs are known to work, like: ctypes, django, pyglet, sqlalchemy, PIL, sqlalchemy. See https://bitbucket.org/pypy/compatibility/wiki/Home for a more exhaustive list.
- 9. pypy – does it work with the modules we use pypy c-api support is beta, worked most of the time but failed with reportlab: Fatal error in cpyext, CPython compatibility layer, calling PySequence_GetItem Either report a bug or consider not using this particular extension <OpErrFmt object at 0x7f1e89587e88> RPython traceback: File "module_cpyext_api_2.c", line 51963, in PySequence_GetItem File "module_cpyext_pyobject.c", line 1071, in BaseCpyTypedescr_realize File "objspace_std_objspace.c", line 3396, in allocate_instance__W_ObjectObject File "objspace_std_typeobject.c", line 3010, in W_TypeObject_check_user_subclass Segmentation fault But this was the only compatibility issue we had running all of our python code under pypy and we could fallback to pure python reportlab extensions anyway.
- 10. pypy – does it run as fast as cpython but! http://speed.pypy.org/
- 11. pypy django benchmark DJANGO_TMPL = Template("""<table> {% for row in table %} <tr>{% for col in row %}<td>{{ col|escape }}</td>{% endfor %}</tr> {% endfor %} </table> """) def test_django(count): table = [xrange(150) for _ in xrange(150)] context = Context({"table": table}) # Warm up Django. DJANGO_TMPL.render(context) DJANGO_TMPL.render(context) times = [] for _ in xrange(count): t0 = time.time() data = DJANGO_TMPL.render(context) t1 = time.time() times.append(t1 - t0) return times
- 12. my csv to xml benchmark def bench(data, output): f = open(data, 'rb') fn = [„age‟,….] reader = csv.DictReader(f, fn) writer = SAXWriter(output) writer.start_doc() writer.start_tag('data') try: for row in reader: writer.start_tag('row') for key in row.keys(): writer.tag(key.replace(' ', '_'), body=row[key]) writer.end_tag('row') finally: f.close() writer.end_tag('data') writer.end_doc()
- 13. my pypy benchmarks https://bitbucket.org/hexdump42/pypy-benchmarks average execution time (in seconds) benchmark cpython pypy-jit pypy-jit 2.7.3 1.9 nightly bm_csv2xml 88.26/94. 28.89 3.0549 x 28.96 3.3723 x 04 faster faster
- 14. my pypy benchmarks https://bitbucket.org/hexdump42/pypy-benchmarks average execution time (in seconds) benchmark cpython pypy-jit pypy-jit 2.7.3 1.9 nightly bm_csv2xml 88.26/94. 28.89 3.0549 x 28.96 3.3723 x 04 faster faster bm_csv 1.54/1.65 5.89 3.8122 x 5.78 3.5025 x slower slower
- 15. my pypy benchmarks https://bitbucket.org/hexdump42/pypy-benchmarks average execution time (in seconds) benchmark cpython pypy-jit pypy-jit 2.7.3 1.9 nightly bm_csv2xml 88.26/94. 28.89 3.0549 x 28.96 3.3723 x 04 faster faster bm_csv 1.54/1.65 5.89 3.8122 x 5.78 3.5025 x slower slower bm_openpyxml 1.31/1.21 3.26 2.4871 x 3.15 2.6051 x slower slower
- 16. my pypy benchmarks https://bitbucket.org/hexdump42/pypy-benchmarks average execution time (in seconds) benchmark cpython pypy-jit pypy-jit 2.7.3 1.9 nightly bm_csv2xml 88.26/94. 28.89 3.0549 x 28.96 3.3723 x 04 faster faster bm_csv 1.54/1.65 5.89 3.8122 x 5.78 3.5025 x slower slower bm_openpyxml 1.31/1.21 3.26 2.4871 x 3.15 2.6051 x slower slower bm_xhtml2pdf 1.91/1.95 3.27 1.7155 x 4.22 2.1637 x slower slower
- 17. my pypy benchmarks https://bitbucket.org/hexdump42/pypy-benchmarks max memory use benchmark cpython pypy-jit pypy-jit 2.7.3 1.9 nightly bm_interp 5412/5248 12556 2.32 x 21880 4.1692 x larger larger bm_csv2xml 7048/7064 55180 7.8292 x 55232 7.8188 x larger larger bm_csv 5812/5180 52200 8.9814 x 52176 10.0726 larger x larger bm_openpyxml 12656/ 77252 6.1040 x 80428 6.3549 x 12656 larger larger bm_xhtml2pdf 48880/ 236792 4.8444 x 101376 2.906 x 34884 larger larger
- 18. what is the pypy jit doing? https://bitbucket.org/pypy/jitviewer/
- 19. modified csv pypy benchmarks https://bitbucket.org/hexdump42/pypy-benchmarks average execution time (in seconds) benchmark cpython pypy-jit pypy-jit 2.7.3 1.9 nightly bm_csv2xml_mod 88.25/90.02 23.65 3.7315 x 23.86 3.7728x faster faster bm_csv_mod 1.62/1.69 1.89 0.8571 x 1.72 0.9825 x slower slower
- 20. is pypy ready for production 1. it runs 2. it satisfies the project requirements 3. its design was well thought out 4. it's stable 5. it's maintainable 6. it's scalable 7. it's documented 8. it works with the python modules we use 9. it is as fast or faster than cpython
- 21. some other reasons to consider pypy cffi – foreign function interface for python - http://cffi.readthedocs.org/ pypy version of numpy py3k version of pypy check out the STM/AME project http://www.pypy.org/howtohelp.html
- 22. contact details Mark Rees mark at censof dot com +Mark Rees @hexdump42 hex-dump.blogspot.com http://www.slideshare.net/hexdump42/pypy-is-it-ready-for-production
Editor's Notes
- I have listed a number of resources that I found helpful but this talk is more about using pypy rather than how it works.
- The first 8 criteria came from a question on stackexchange, the last 2 are my additional requirements. A little detailed definition than the management version: it runs, it makes money.You may disagree with the list but it’s the criteria I will be using. Also I will be biased towards the needs of the company I work for. So let’s work thru the list to see how pypy stacks up.
- It runs great on x86 32bit and 64bit platforms under Linux, Windows and OS X. There are other backend implementations – ARM, PPC, Java & .NET VM’s. Some have had more love than others. Pypy implements the Python language version 2.7.2, supporting all of the core language passing the Python test suite. It supports most of the standard library modules. It has support for CPython C API but it is beta quality. I will go into more detail about standard library and other module compatibility later in the talk.
- I am not a language interpreter designer so I cannot really comment on the design but you would assume with the number of years development & refactoring by the pypy team it is a well thought out design.With regards maintainability, due to much of the pypytoolchain using RPython and the complexity of the architecture I feel it is hard for the normal python programmer to be able to contribute to coding maintenance of pypy. The learning curve is steep but certainly maintainability f the pure-python portions of the pypy components are easier.
- As I said before pypy implements python language version 2.7.2
- As at pypy 1.9 c-api support is considered beta and while it worked for many of the modules we use e.g PIL, it failed with the c extensions for reportlab. This wasn’t a show-stopper as these extensions also have python equivalents in the standard reportlab distribution. Of course, our python library use will be different from yours, so you experience will be dufferent as well.
- The above plot represents PyPy trunk (with JIT) benchmark times normalized to Cpython as at 12 August 2012. Smaller is better.The standard benchmarks are limited to one domain and do not in a lot of cases cover complete processes or workloads. For example:
- Thedjango benchmark in the standard pypy benchmark suite and was originally part of the unladen swallow benchmarks. So this benchmark is only testing the template rendering performance of django. There is nothing wrong with this and it’s a standard benchmark technique. So if you see the results of this benchmark, then it’s likely the performance of django template rendering under pypy would be faster than cpython. Does this mean your django website perfromance would be better? Maybe.
- My benchmarks are a little different from the standard pypy as they simulate workloads similar to what we use python for at work. So rather than benchmarking a small portion or function as the standard benchmarks do, mine cover either a complete process or the majority of one. So my benchmarks are impacted by io as well as the in-program execution. Since the majority of the non web use of in our workplace is extract/transform/load (ETL) tasks, this is what the benchmarks are doing.
- To perform the benchmarks, a clone of the pypy benchmark tools was done and my benchmarks added to it. You can see these at https://bitbucket.org/hexdump42/pypy-benchmarks. The benchmarks were run on a VMWare virtual instance with 2GB RAM, 1 Core 64bit running Scientific Linux 6.2. The base CPython used was 2.7.2 and comparison benchmarks were run against pypy-jit release 1.9 and the nightly pypy-jit build of August 14 2012 collecting avg execution time and memory use. 50 iteration benchmark runs. So for the bm_csv2xml benchmark, 100Mb csv file of census data to loaded, parsed and output as xml to a file. So it is faster than cpython, things are looking good. But I had hoped it would be a little better. So
- I created a benchmark of just the csv load and parse and was surprised to see that it was slower than the cpython equivalent, so in my previous benchmark the xml output was what gave the improved performance under pypy.
- .
- The bm_interp benchmark just provides a baseline of what memory just the interpreter uses prior to any real work.Just in case these benchmark results were related to something related to my vm configuration, I also reran these benchmarks on physical hardware and obtained similar results. If I had stopped here, you would have say that pypy didn’t meet my production criteria but since some of the components that affect the performance are in python under pypy, I decided to see why performance wasn’t the same or better than cpython. I decided to start with the low hanging fruit – csv performance.
- You can use the pypyjit viewer to see what is happening and of course I can review the source of _csv.py since it’s written in pure python. Thanks to some input in pypy issue tracker https://bugs.pypy.org/issue641
- I was able to after a number of attempts modify _csv.py so that bm_csv benchmark performed at the same speed as cpython. This also gave a small performance improvement in the bm_csv2xml benchmark. Based on thee improvements, it is very likely we will use pypy in place of cpython for the ETL where we load csv files and convert to xml. I also intend to investigate where the performance bottlenecks are in the other ETL process benchmarks to see if we can get the gains sinmilar to what we get with pypy for the bm_csv2xml benchmark.
- If we revisit the definition of production ready, certainly if we just use items 1-7 as the criteria, pypy is certainly production ready when compared with other python implementations that are being used in production. If you want to run existing python code under pypy, then pypy compatibility with non standard python libraries needs to be considered and getting your hands dirty by running the code under pypy is really the best way to see if pypy will work. If nothing else you can report an issue to the pypy team and they can use it to improve compatibility. And will our company be deploying anything in production under pypy? It is likely sometime this year we will look at deploying it for certain ETL workloads due to measured benchmark performance. The additional memory overhead isn’t an issue for us. So my recommendation is that if you are looking for performance improvements, give pypy a go, you may be surprised.But performance shouldn’t be the only reason to consider pypy, there are various pypy side projects that will have good benefits for the python community as a whole. Last week the pypy team released cffi Foreign Function Interface for Python calling C code. The aim of this project is to provide a convenient and reliable way of calling C code from Python. It is
- But performance shouldn’t be the only reason to consider pypy, there are various pypy side projects that will have good benefits for the python community as a whole. Last week the pypy team released cffi Foreign Function Interface for Python calling C code. The aim of this project is to provide a convenient and reliable way of calling C code from Python. It works with both pypyabdcpython 2.6+. The pypy team are working a pypy implementation of numpy and are close to a py3k language compliant version. If you want to help with pypy, check out the howto help page & the donation page.