4 ms·
CPython is what's slow, not Python itself. The main reason CPython is slow is that it's purely a bytecode interpreter and it makes no use of AoT or JiT compilat
by wassenaar10 6y ago
CPython is what's slow, not Python itself. The main reason CPython is slow is that it's purely a bytecode interpreter and it makes no use of AoT or JiT compilation unlike the JVM, CLR, or V8 JavaScript engine. If anything, the rapid growth and adoption of Python gives me hope that we'll see something akin to the V8 engine for Python. Yes, things like Cython and PyPy exist but both have their issues.
Javascript had a reputation for being horribly slow before modern JIT compiled JS engines were created. I believe that around the time the V8 project began, a non-trivial number of browsers were using an AST-walk interpreter to execute JS (you can imagine how slow that was). If you look at some benchmarks for how V8 JS (for example Node.JS) performs relative to Java, C#, and C++, you will generally see that the performance gap between JS and Java/C# is comparable to the gap between Java/C# and C++. CPython, of course, is a lot slower.
There's nothing about Python that's fundamentally more dynamic than Javascript, though correct me if I'm wrong. Both languages have the ability to add arbitrary fields to objects at runtime (though I would say Python's syntax and object model tries to sway you away from doing it more so that JS), both languages have similar type systems and essentially fully first-class functions with closures, and both languages have an eval method that can execute any string as source code. The saying goes, "The squeaky wheel gets the grease", and for a long time Javascript was the squeaky wheel that everyone complained about but still had to use in order to target web browsers. That's what encouraged a huge company like google to invest resources into making a fast Javascript engine. I would not be surprised if something similar ends up happening with python.
- anonymoushn 6y agoI agree with your comment but don't expect improvements to Python runtimes because the high-performance libraries people depend on are tied up with the guts of cpython. Edit: Actually, for alphazero specifically, it would not be enough to make cpython run as fast as V8. I have implemented the alphazero training pipeline in torch, which uses a dynamic language runtime with performance comparable to V8. After spending weeks optimizing my MCTS, rules engine, and game state encoding and decoding, I still found that the CPU time consumed by these things caused substantial underutilization of the GPU. But at V8 levels of performance this is more like "it takes 2x as long to train" rather than "it is not viable to train." If I had done a better job of writing my above comment I would have made it clearer that this is not mostly about python-for-data-science. Most "right tools for the job" for other jobs are also points in tradeoff space that give up a lot of expressive power, ability to ensure correctness, performance, or all 3 in exchange for benefits that may only make sense over very short time horizons.