4 ms·

Title should say 2013. These days, PyPy is way past 25% average speedup with respect to CPython. /edit to be fair, the project README points out the difference

Title should say 2013. These days, PyPy is way past 25% average speedup with respect to CPython. /edit to be fair, the project README points out the difference in goals and performance between Falcon and PyPy quite nicely: https://github.com/rjpower/falcon/blob/master/README.md https://github.com/rjpower/falcon/blob/master/README.md

haberman 11y ago
I thought the 25% number was Falcon vs. CPython, not PyPy vs. CPython. The paper suggests (though does not say directly) that PyPy is faster than Falcon, and that the only benefit of Falcon is compatibility with existing C extensions.
- ProblemFactory 11y ago
  But compatibility with C extensions is a major selling point. 25% speedup for pure Python code is not that appealing in numerical analysis code, when you can use NumPy, or sprinkle a few typedefs into a critical function and compile with Cython for a 1000x speedup. If C extension compatibility is broken, then many Python programs will altogether still be slower, despite the pure python speedup.
  - awinter-py 11y ago
    cython community can definitely use some love -- there's a ton of low-hanging fruit (unboxing arrays of extension classes, for example) they haven't gotten to because of time / funding constraints. Not an apples to apples comparison, but my guess is the state of the art of JIT is way ahead of what the cython compiler can detect; some of the JIT tricks will likely work in the cython static translation step.
    - awinter-py 11y ago
      And to be clear I love cython, it's very useful as-is -- there's a large community of people for whom C & python expertise have gone hand in hand for years, and cython is the tool they end up using to max productivity and minimize surprises.
- Animats 11y ago
  That's about right. That's about where Unladen Swallow maxed out. To get beyond that point, you have to do more global analysis and JIT compilation and recompilation, as PyPy does. Every Python symbol reference requires a dictionary lookup. Every function call and operator requires that the type of the left hand side be examined for dispatching purposes. More than 99% of the time, the symbol and type will be the same as last time, and it's a huge win to assume that it will be and compile code for that case. You still have to be prepared for the times when it isn't, and have a backup system. That's basically what PyPy does. More stuff is mutable in Python than really needs to be mutable.
  - rcarmo 11y ago
    That is true. I've been fooling around with Hy (hylang.org) for a fairly long time because it's nicer than Clojure for doing glue, and that has made me wonder how fast some things would go if Python had native immutable data types.
  - gsnedders 11y ago
    > That's about right. That's about where Unladen Swallow maxed out. To get beyond that point, you have to do more global analysis and JIT compilation and recompilation, as PyPy does. Unladen Swallow did JIT compilation and recompilation, despite not doing better.
- piquadrat 11y ago
  Rereading my comment, it can easily be misunderstood. Sorry about that. The 25% average speedup they cite is indeed relative to CPython. Thanks for clarifying!
- awinter-py 11y ago
  I think the newest version of RPython has better FFI; they've been blogging about lxml compatibility for a few months.
dang 11y ago
Thanks, we added the year above.
joejev 11y ago
pypy only does python 2. Some people want to use the new features of python.
joshmaker 11y ago
The Pyston team at Dropbox has a presentation where they say the "real world" performance metrics aren't as good for PyPy as the benchmarks would suggest, allegedly slower than cpython on many metrics. http://www.slideshare.net/KevinModzelewski/pyston-talk-111015#42 http://www.slideshare.net/KevinModzelewski/pyston-talk-11101... It's an argument I haven't heard anywhere else (and one I'm not in a position to substantiate) but presumably Dropbox, who use Python at scale, have as valid perspective on this issue as anyone.
- PostOnce 11y ago
  I wrote a game renderer with pygame, its >10x faster in pypy... it's voxels (in the comanche sense). That's just an anecdote but obviously you should check your use case and find what tool is best suited for your project. There is no magic cure-all, but in my experience pypy comes close. I'm pretty confident it's also going to be a magic speed boost for a decent size web app I work on, but it remains to be tested with this particular app so I'll check it out... The most bulletproof way to find out what's faster is to test it.
  - kdeldycke 10y ago
    Comanche's voxels is an elevation map.
    - PostOnce 10y ago
      That's why I said "in the comanche sense", since this style of raycasting was commonly and erroneously referred to as "voxels" in the 90s (all other raycasters having basically flat floors). "elevation map" doesn't mean anything in terms of projection, you can project an elevation map onto a 2D display in a hundred ways, "raycaster" does mean something here, a raycasted elevation map or raycasted heightfield is what this is, anyway it's just an example of what types of problems can be solved 10x faster with pypy.

haberman 11y ago

I thought the 25% number was Falcon vs. CPython, not PyPy vs. CPython. The paper suggests (though does not say directly) that PyPy is faster than Falcon, and that the only benefit of Falcon is compatibility with existing C extensions.

ProblemFactory 11y ago
But compatibility with C extensions is a major selling point. 25% speedup for pure Python code is not that appealing in numerical analysis code, when you can use NumPy, or sprinkle a few typedefs into a critical function and compile with Cython for a 1000x speedup. If C extension compatibility is broken, then many Python programs will altogether still be slower, despite the pure python speedup.
- awinter-py 11y ago
  cython community can definitely use some love -- there's a ton of low-hanging fruit (unboxing arrays of extension classes, for example) they haven't gotten to because of time / funding constraints. Not an apples to apples comparison, but my guess is the state of the art of JIT is way ahead of what the cython compiler can detect; some of the JIT tricks will likely work in the cython static translation step.
  - awinter-py 11y ago
    And to be clear I love cython, it's very useful as-is -- there's a large community of people for whom C & python expertise have gone hand in hand for years, and cython is the tool they end up using to max productivity and minimize surprises.
Animats 11y ago
That's about right. That's about where Unladen Swallow maxed out. To get beyond that point, you have to do more global analysis and JIT compilation and recompilation, as PyPy does. Every Python symbol reference requires a dictionary lookup. Every function call and operator requires that the type of the left hand side be examined for dispatching purposes. More than 99% of the time, the symbol and type will be the same as last time, and it's a huge win to assume that it will be and compile code for that case. You still have to be prepared for the times when it isn't, and have a backup system. That's basically what PyPy does. More stuff is mutable in Python than really needs to be mutable.
- rcarmo 11y ago
  That is true. I've been fooling around with Hy (hylang.org) for a fairly long time because it's nicer than Clojure for doing glue, and that has made me wonder how fast some things would go if Python had native immutable data types.
- gsnedders 11y ago
  > That's about right. That's about where Unladen Swallow maxed out. To get beyond that point, you have to do more global analysis and JIT compilation and recompilation, as PyPy does. Unladen Swallow did JIT compilation and recompilation, despite not doing better.
piquadrat 11y ago
Rereading my comment, it can easily be misunderstood. Sorry about that. The 25% average speedup they cite is indeed relative to CPython. Thanks for clarifying!
awinter-py 11y ago
I think the newest version of RPython has better FFI; they've been blogging about lxml compatibility for a few months.

dang 11y ago

Thanks, we added the year above.

joejev 11y ago

pypy only does python 2. Some people want to use the new features of python.

joshmaker 11y ago

The Pyston team at Dropbox has a presentation where they say the "real world" performance metrics aren't as good for PyPy as the benchmarks would suggest, allegedly slower than cpython on many metrics. http://www.slideshare.net/KevinModzelewski/pyston-talk-111015#42 http://www.slideshare.net/KevinModzelewski/pyston-talk-11101... It's an argument I haven't heard anywhere else (and one I'm not in a position to substantiate) but presumably Dropbox, who use Python at scale, have as valid perspective on this issue as anyone.

PostOnce 11y ago
I wrote a game renderer with pygame, its >10x faster in pypy... it's voxels (in the comanche sense). That's just an anecdote but obviously you should check your use case and find what tool is best suited for your project. There is no magic cure-all, but in my experience pypy comes close. I'm pretty confident it's also going to be a magic speed boost for a decent size web app I work on, but it remains to be tested with this particular app so I'll check it out... The most bulletproof way to find out what's faster is to test it.
- kdeldycke 10y ago
  Comanche's voxels is an elevation map.
  - PostOnce 10y ago
    That's why I said "in the comanche sense", since this style of raycasting was commonly and erroneously referred to as "voxels" in the 90s (all other raycasters having basically flat floors). "elevation map" doesn't mean anything in terms of projection, you can project an elevation map onto a 2D display in a hundred ways, "raycaster" does mean something here, a raycasted elevation map or raycasted heightfield is what this is, anyway it's just an example of what types of problems can be solved 10x faster with pypy.