Hacker News Reader

Comment by piquadrat | Hacker News Reader

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

View on HN

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-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.

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.

Comanche's voxels is an elevation map.

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.

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.

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.

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.

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.

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.

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.

> 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.

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!

I think the newest version of RPython has better FFI; they've been blogging about lxml compatibility for a few months.

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

Thanks, we added the year above.

Reply on news.ycombinator.com