4 ms·

This is great. Can't wait until Python 3.5 support is out of beta. Just out of curiosity, I'd love to hear from others who've used PyPy for their web apps. Are

This is great. Can't wait until Python 3.5 support is out of beta. Just out of curiosity, I'd love to hear from others who've used PyPy for their web apps. Are there any issues to look out for? I remember that a few years ago, packages like psycopg2 were not compatible, which made the migration somewhat difficult. Would love to hear real-world experiences here.

mattip 9y ago
We have made alot of progress over the past few years, especially with compatibility . An example of a web stack is crossbar.io who recommend it for production and even got their stack running with PyPy on a rasberryPi [0] [0] https://crossbario.com/blog/Autobahn-Pi-Benchmark/ https://crossbario.com/blog/Autobahn-Pi-Benchmark/
jstarfish 9y ago
I use PyPy almost exclusively. I like the availability of their precompiled binaries, and other peoples' benchmarking criticisms aside it's orders of magnitude faster than standard Python in all of my actual applications. psycopg2cffi fixed the psycopg2 issue some time ago. I've run into compatibility issues with packages that reference math-centric libs (matplotlib?) but aside from that I've been quite happy with it.
- 3131s 9y ago
  So if I have an existing Django application in production, assuming no package compatibility issues, how long might it take to get it running with PyPy?
  - fijal 9y ago
    I would say, if you're familiar with virtualenv and things like that, about 15 minutes
  - StavrosK 9y ago
    I have a production Django application (the https://www.pastery.net https://www.pastery.net pastebin). Just for fun, I'm going to change the container's image from python:3 to pypy:3 and document what happens here. EDIT: * Failed building psycopg2. Apparently I need to use psycopg2cffi instead. Retrying... * manage.py now can't import Django. Hmm. * Yeah, I have no idea why it can't import Django. I took most of the settings out of settings.py, thinking it somehow caused an ImportError, but it still fails. I think I have to give up at this point, as I have no more guesses. * Turns out manage.py was trying to launch `/usr/bin/env python` and it needed `/usr/bin/env pypy3`. Seems odd to include a `python` binary on the image and not just alias it to `pypy3`, but it is what it is. Continuing... Welp, everything seems to be running just fine. Here's the diff of all the changes I had to make: https://www.pastery.net/rrjdfj/ https://www.pastery.net/rrjdfj/ Basically, install psycopg2cffi instead of psycopg2, use pypy3 for the interpreter instead of python, and add two lines to settings.py. All in all, pretty damn short!
    - silviogutierrez 9y ago
      Awesome investigation! Any cursory benchmarks? Does it feel faster?
      - StavrosK 9y ago
        I couldn't tell you, really, as I'm just browsing on my local machine. It feels about the same, but I didn't expect to see much difference.
    - 3131s 9y ago
      Thanks! I'll be doing this soon too then. Most of my apps don't rely on too many obscure packages and / or really large scientific computing packages, so I doubt I'll run into many problems either.
- chubot 9y ago
  What kind of applications are you using it for? Coincidentally I tried PyPy today for my shell, which is around 14K lines of completely unoptimized Python code [1]. I have never used PyPy before, despite being a long-time Python programmer. I didn't expect PyPy to speed it up, just based on my impressions of the kind of workloads PyPy excels at. In my first test case (parsing a 976 line shell script), PyPy took 2.0 seconds and Cpython took 1.0. And that 2x slower number held up for other a couple other tests. I will probably try running the benchmark in a loop to see if PyPy's JIT warms up (does it do that?). But I wasn't really expecting to use PyPy -- I just wanted to see how it does, because there aren't many ways to speed up my code without rewriting a good portion of it. My impression is that JITs don't work well in general for certain workloads, not just PyPy. IIRC LuaJIT is actually slower than Lua for string-processing workloads. It makes a lot of sense in say machine learning applications which are all floating point calculations. But string processing is probably dominated by allocations and locality, and the JIT doesn't do very much there, whether it's LuaJIT or PyPy. [1] http://www.oilshell.org/ http://www.oilshell.org/
  - vram22 9y ago
    Have you tried using Cython to see if it speeds up your code?
  - omaranto 9y ago
    I'd love to see a benchmark on which LuaJIT is significantly slower than Lua, if you have a link.
    - chubot 9y ago
      I probably overstated... I don't think JITs including LuaJIT do much for string manipulation, but that would mean it's on par with Lua. Off the top of my head I think of Lua/Python as 10-100x slower than C, but LuaJIT might get you within 2x for some numerical workloads. But it will not get you within 2x for string workloads -- it's still in the 10x or worse category. Someone reported a slower benchmark here but the maintainer argued that is invalid. But he says all the time is within C functions, which is what I was getting at. https://www.freelists.org/post/luajit/Luajit-string-concatenation-performance,10 https://www.freelists.org/post/luajit/Luajit-string-concaten... A couple people mention string performance here, without many details: https://news.ycombinator.com/item?id=12573981 https://news.ycombinator.com/item?id=12573981 I think the bottom line is that the semantics of Lua strings are completely different than how you manage strings in C, so there's a limit to how much you can optimize the program, even if you have a lot of time to (which the JIT does not.)
rcarmo 9y ago
I've yet to get PyPy to work well with uwsgi, but I haven't tried it with the past 3-4 releases. However, since uwsgi embeds the runtime in its worker processes, that is sort of expected. (feedback on this would be great, since someone else might have tried it recently)
ericfrederich 9y ago
3.5 was the first Python3 worth using according to Raymond Hettinger... but I think it was 3.6 that made dicts ordered by default and also includes f-strings. 3.6 is the one to have ;-)
- pjenvey 9y ago
  3.6's order-preserving dict was first implemented by PyPy (so it's already had it for years, even in pypy2) and f-strings were back ported to pypy3 too.
- lozenge 9y ago
  dicts being ordered is still an implementation detail. The only place they are officially ordered is where the come from the catch-all keyword arguments in your function's signature.
jdenning 9y ago
My only experience was a couple of years back, but I remember that there was a "warm-up" period where resource utilization was substantially worse than pre-pypy conversion, then performance would improve. Again, I haven't followed recent developments, so this may be less of an issue now. Edit: I should add - we loved it! Pypy was like a magic bullet that solved our performance problems.

mattip 9y ago

We have made alot of progress over the past few years, especially with compatibility . An example of a web stack is crossbar.io who recommend it for production and even got their stack running with PyPy on a rasberryPi [0] [0] https://crossbario.com/blog/Autobahn-Pi-Benchmark/ https://crossbario.com/blog/Autobahn-Pi-Benchmark/

jstarfish 9y ago

I use PyPy almost exclusively. I like the availability of their precompiled binaries, and other peoples' benchmarking criticisms aside it's orders of magnitude faster than standard Python in all of my actual applications. psycopg2cffi fixed the psycopg2 issue some time ago. I've run into compatibility issues with packages that reference math-centric libs (matplotlib?) but aside from that I've been quite happy with it.

3131s 9y ago
So if I have an existing Django application in production, assuming no package compatibility issues, how long might it take to get it running with PyPy?
- fijal 9y ago
  I would say, if you're familiar with virtualenv and things like that, about 15 minutes
- StavrosK 9y ago
  I have a production Django application (the https://www.pastery.net https://www.pastery.net pastebin). Just for fun, I'm going to change the container's image from python:3 to pypy:3 and document what happens here. EDIT: * Failed building psycopg2. Apparently I need to use psycopg2cffi instead. Retrying... * manage.py now can't import Django. Hmm. * Yeah, I have no idea why it can't import Django. I took most of the settings out of settings.py, thinking it somehow caused an ImportError, but it still fails. I think I have to give up at this point, as I have no more guesses. * Turns out manage.py was trying to launch `/usr/bin/env python` and it needed `/usr/bin/env pypy3`. Seems odd to include a `python` binary on the image and not just alias it to `pypy3`, but it is what it is. Continuing... Welp, everything seems to be running just fine. Here's the diff of all the changes I had to make: https://www.pastery.net/rrjdfj/ https://www.pastery.net/rrjdfj/ Basically, install psycopg2cffi instead of psycopg2, use pypy3 for the interpreter instead of python, and add two lines to settings.py. All in all, pretty damn short!
  - silviogutierrez 9y ago
    Awesome investigation! Any cursory benchmarks? Does it feel faster?
    - StavrosK 9y ago
      I couldn't tell you, really, as I'm just browsing on my local machine. It feels about the same, but I didn't expect to see much difference.
  - 3131s 9y ago
    Thanks! I'll be doing this soon too then. Most of my apps don't rely on too many obscure packages and / or really large scientific computing packages, so I doubt I'll run into many problems either.
chubot 9y ago
What kind of applications are you using it for? Coincidentally I tried PyPy today for my shell, which is around 14K lines of completely unoptimized Python code [1]. I have never used PyPy before, despite being a long-time Python programmer. I didn't expect PyPy to speed it up, just based on my impressions of the kind of workloads PyPy excels at. In my first test case (parsing a 976 line shell script), PyPy took 2.0 seconds and Cpython took 1.0. And that 2x slower number held up for other a couple other tests. I will probably try running the benchmark in a loop to see if PyPy's JIT warms up (does it do that?). But I wasn't really expecting to use PyPy -- I just wanted to see how it does, because there aren't many ways to speed up my code without rewriting a good portion of it. My impression is that JITs don't work well in general for certain workloads, not just PyPy. IIRC LuaJIT is actually slower than Lua for string-processing workloads. It makes a lot of sense in say machine learning applications which are all floating point calculations. But string processing is probably dominated by allocations and locality, and the JIT doesn't do very much there, whether it's LuaJIT or PyPy. [1] http://www.oilshell.org/ http://www.oilshell.org/
- vram22 9y ago
  Have you tried using Cython to see if it speeds up your code?
- omaranto 9y ago
  I'd love to see a benchmark on which LuaJIT is significantly slower than Lua, if you have a link.
  - chubot 9y ago
    I probably overstated... I don't think JITs including LuaJIT do much for string manipulation, but that would mean it's on par with Lua. Off the top of my head I think of Lua/Python as 10-100x slower than C, but LuaJIT might get you within 2x for some numerical workloads. But it will not get you within 2x for string workloads -- it's still in the 10x or worse category. Someone reported a slower benchmark here but the maintainer argued that is invalid. But he says all the time is within C functions, which is what I was getting at. https://www.freelists.org/post/luajit/Luajit-string-concatenation-performance,10 https://www.freelists.org/post/luajit/Luajit-string-concaten... A couple people mention string performance here, without many details: https://news.ycombinator.com/item?id=12573981 https://news.ycombinator.com/item?id=12573981 I think the bottom line is that the semantics of Lua strings are completely different than how you manage strings in C, so there's a limit to how much you can optimize the program, even if you have a lot of time to (which the JIT does not.)

rcarmo 9y ago

I've yet to get PyPy to work well with uwsgi, but I haven't tried it with the past 3-4 releases. However, since uwsgi embeds the runtime in its worker processes, that is sort of expected. (feedback on this would be great, since someone else might have tried it recently)

ericfrederich 9y ago

3.5 was the first Python3 worth using according to Raymond Hettinger... but I think it was 3.6 that made dicts ordered by default and also includes f-strings. 3.6 is the one to have ;-)

pjenvey 9y ago
3.6's order-preserving dict was first implemented by PyPy (so it's already had it for years, even in pypy2) and f-strings were back ported to pypy3 too.
lozenge 9y ago
dicts being ordered is still an implementation detail. The only place they are officially ordered is where the come from the catch-all keyword arguments in your function's signature.

jdenning 9y ago

My only experience was a couple of years back, but I remember that there was a "warm-up" period where resource utilization was substantially worse than pre-pypy conversion, then performance would improve. Again, I haven't followed recent developments, so this may be less of an issue now. Edit: I should add - we loved it! Pypy was like a magic bullet that solved our performance problems.