9 ms·
How fast can we make interpreted Python? (2013)
- _ihaque 11y agoStack->register JIT compiler for Python that maintains compatibility with existing C extensions because it runs as an extension within CPython. Average of 25% faster to up to 2.5x on the benchmarks in the paper. Source link: https://github.com/rjpower/falcon/ https://github.com/rjpower/falcon/ (doesn't show up in the paper till the very end!)
- piquadrat 11y agoTitle 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 agoI 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 agoBut 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 agocython 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 agoAnd 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 agoThat'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 agoThat 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 agoRereading 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 agoI think the newest version of RPython has better FFI; they've been blogging about lxml compatibility for a few months.
- dang 11y agoThanks, we added the year above.
- joejev 11y agopypy only does python 2. Some people want to use the new features of python.
- joshmaker 11y agoThe 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 agoI 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 11y agoComanche's voxels is an elevation map.
- PostOnce 11y agoThat'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.
- continuations 11y agoHow does Falcon compare to PyPy performance wise?
- vegabook 11y agoAh yes. 25% faster. I get 50x faster (that would be 5000%) just dipping into Numpy when I need to (admittedly with AVX), and C when I have to. Both are like, trivially easy. Why are we bothering with making native Python marginally faster when it is already the perfect tool for the mission it is there to accomplish (glue), and there are dozens of other tools which are optimized for performance?
- rcarmo 11y agoBecause we need faster glue? :)
- Animats 11y ago"Both are like, trivially easy." Until you screw up memory allocation and have to debug. There's a race condition in Python 3's CPickle that corrupts memory.[1] I can't reproduce it well enough to submit a bug report that won't be ignored. [1] http://bugs.python.org/issue23655 http://bugs.python.org/issue23655
- deleted 11y ago[deleted]
- deleted 11y ago[deleted]
- smortaz 11y agothere's also Microsoft's effort: https://github.com/Microsoft/Pyjion https://github.com/Microsoft/Pyjion [disclaimer]
- seabrookmx 11y agoThis is actually really cool!
- oldmanjay 11y agoWhat are you disclaiming? I have to admit, having been a bit baffled when people started disclaiming their credentials against all definitional expectation, just seeing a bare disclaimer with nothing obviously being disclaimed, I am completely confused.
- heydenberk 11y agoPrevious posting: https://news.ycombinator.com/item?id=6112995 https://news.ycombinator.com/item?id=6112995 25 comments and good discussion there.
- epx 11y agoQuite old, plain Python is still slow but PyPy is in the league of Node.js. I rewrote the same program (compare two images, generate a third that shows the diff) in a number of languages. Considering CPython as the reference implementation (1x), I got 100x in Rust, 60x in Go, 12x in Node.js and 10-11x in PyPy. Initially I got 4x with PyPy but I did a light refactor, removing some map()s and zip()s that were gratitious (3-element lists) and then PyPy went real fast.
- frozenport 11y agoAs a C++ developer I find it hilarious that Node.js is a high performance league! ( your benchmark for example shows Rust as 6x faster)
- deleted 11y ago[deleted]
- chrisseaton 11y agoBut it's high performance given the semantics of the language. The work that has gone into making V8 perform as it does is extraordinary and should be respected, not mocked as 'hilarious'.
- yeukhon 11y agoI believe the high performance usually refers to NodeJS' non-blocking I/O.
- frozenport 11y agoThe benchmarks show that by using another language his code went 8x faster. Perhaps if he optimized his C++ it would go even faster. It's funny that people are saying 10x off the theoretical is high performance. I wonder if these people are living in a Javascript bubble.
- sorenjan 11y agoI've never used Rust, how would it compare to a C++ solution?
- pepijndevos 11y agoFor all those talking about PyPy, have a look at Pyston, an ongoing effort by Dropbox to build a fast Python. https://github.com/dropbox/pyston https://github.com/dropbox/pyston
- forgotpwtomain 11y agoAny idea why they decided to write their own JITed python implementation rather than putting in additional support for PyPy ?
- Fede_V 11y agoC-API compatibility, I'm guessing. I agree it was of a strange choice though.
- andreasvc 11y agoPyPy also has higher memory usage.
- joshmaker 11y agoAccording to this slide their "real world" tests of PyPy didn't live up to the benchmarks, and in fact showed "no clear improvement" compare with cpython http://www.slideshare.net/KevinModzelewski/pyston-talk-111015 http://www.slideshare.net/KevinModzelewski/pyston-talk-11101...
- txdv 11y agoI'm kinda jealous that there is so much effort put into Python... I like to use ruby as a scripting language...
- amelius 11y agoWhy not write a Py->JS transpiler to solve the efficiency problem?
- rpearl 11y agoI can't tell if you're joking, but if not... No, JS isn't more efficient than Python.
- infogulch 11y agoI couldn't tell either. Poe's law in full effect.
- RubyPinch 11y agohaving a Python JITing VM written in python, compiled to javascript, can actually be faster than CPython (after warmup!) https://www.rfk.id.au/blog/entry/pypy-js-faster-than-cpython/ https://www.rfk.id.au/blog/entry/pypy-js-faster-than-cpython...
- Johnny_Brahms 11y agoMaybe not, but if you are doing single threaded stuff in python you will probably get better performance by using node. Now, I'm no python or javascript programmer, but I generally get a lot better performance for small scripts using node.
- deleted 11y ago[deleted]
- outworlder 11y agoSarcasm detector is also failing. But even compiling to C would not magically solve the issues.
- talideon 11y agoA big part of the reason why the likes of V8 are fast is because they can concentrate on being single-threaded. If you wanted to write a transpiler, it would need to be targeted at a JS implementation that allowed for multiple threads to be run at the same time. If you did that, you'd have a JS runtime with similar problems to CPython.
- antman 11y agoI have been using cython, as presented here [0] with huge speedups. Prototype in python and then make a few changes to produce python code. https://spacy.io/blog/writing-c-in-cython https://spacy.io/blog/writing-c-in-cython
- eveningcoffee 11y agoIs it at all possible to make Python really fast given that it depends on GIL, that to my understanding makes Python performance memory bound?
- hodwik 11y agoCould you explain why GIL wouldn't make it CPU bound, rather than memory bound?
- eveningcoffee 11y agoI am sorry, but by memory I meant cache memory that is in fact inside the CPU. This is error on my side. I read [0] and could not infer anything to confirm my understanding, but if we consider the semantics of GIL, then there should be some form of guarantee in place that two CPU cores see the coherent picture of the cache (other way two threads would see incoherent values of the same variable or would not see the changes at all). This is usually archived by some form of memory barriers and flushing the registers into memory and this by my experience (that comes from Java) makes the code order of magnitude or two slower. [0] https://wiki.python.org/moin/GlobalInterpreterLock https://wiki.python.org/moin/GlobalInterpreterLock
- andreasvc 11y agoThe GIL is an issue when you want parallelism. It is not relevant when talking about single thread performance.
- eveningcoffee 11y agoAs I understand it, it eliminates some optimization possibilities and adds overhead. I do not have time to check the Python code to see how it is actually implemented (hence my question) but based on my knowledge it would imply at least a CAS operation to check and take the lock, writing the register values into memory (cache) and applying a memory barrier. You can not keep the values in the registries (elimination of optimization possibilities) and you add considerable overhead by needing memory barriers and CAS operations. I am not claiming that Python does it like this, I am just assuming that it should do it like this to obtain the guaranties of GIL.
- baccheion 11y agoVery.. if a VM or JIT compiler is added to the mix, and optional type hints. There are many potential Python optimizations that can't be done that are suddenly possible if something can provide real time code monitoring/optimization.
- mangeletti 11y agoSomething worth noting: Python 3.6 has a number of refactorings of standard library components[1], and while that doesn't effect the CPython interpreter itself, these enhancements should do a lot to speed up applications that make heavy use of the standard library. 1. Some are mentioned at https://docs.python.org/3.6/whatsnew/3.6.html https://docs.python.org/3.6/whatsnew/3.6.html (search page for "fast")
- exabrial 11y agoBut why? I'm not trolling, I mean this as sincere non hostile criticism... Static types alone improve code quality and execution speed, and it's been shown hardly anyone actually exploits dynamic types anyway.