Python and speed: Unladen Swallow, PyPy, Cython
A brief translation of the discussion of Recommendation against Python? :
kng
I’ve heard that Google employees don’t recommend using Python for new projects, which seems silly to me, considering how much Python code and support for the Python language itself comes from Google. I started searching for information, but found nothing. Do you know something about this or is it just a rumor?
Collin winder
Even simple common sense limits the applicability of Python when it comes to Google’s scale - it’s not as fast as Java or C ++, work with threads is lame, more memory is used, etc. One of the requirements that we face when designing new systems is “What will we do if the load increases 10 or 100 times? What will we do if the whole planet decides that our new service is awesome? ”Any technology that complicates compliance with this requirement — and I believe that Python falls into this category — must be rejected and even its other usefulness does not play an important role in this case. You have to balance the strengths and weaknesses of Python - your developers can be more productive using Python, but if they have to work hard on scaling under a heavy load, will you be able to get ahead of Python? Etc.
...
Unladen Swallow plans to shift this balance - to make it possible to use Python in a larger number of projects, where it is still irrational to use it now. But it will not be a panacea. Python will still be slower than C or Java, will use more memory and work terribly with threads until someone decides to invest resources in Python in an amount comparable to the resources that Sun invested in the JVM. I hope that attention to the performance of Python on the part of developers will be avalanche-like - the more companies are interested in this, the more resources will be invested, the more graduate students will work on Python (and share the results of their work), etc.
Luis gonzalez
It is clear that Python will be slower than C or Java, but I’m wondering - how fast will Python (in our case, Unladen Swallow) work compared to the V8 js engine? Do you think it will be possible to catch up with the V8? Or do you need a complete rewrite (interpreter) in order to catch up with him?
')
Collin winter
I don't think it is possible to make the CPython implementation as fast as the V8 or SquirrelFish Extreme engines, which are specifically designed for speed. We came up with a number of optimizations that are already very difficult to implement on the basis of CPython and we had to abandon them. Being an open-source project, which enthusiasts are engaged in, CPython dictates other priorities than V8 - CPython places particular emphasis on simplicity, on the idea that a simple slow core is easier to support for people who do it in their spare time than a more complex fast core.
I hope that one of the alternative implementations of Python will ultimately achieve a serious performance gain without reference to C-level backward compatibility (with CPython). We are acting within the boundaries of “What should we do to make things better right now ?”, While PyPy projects work with productivity in perspective “What should we do if we are ready to spend ten years to do everything right?” .
Tom machinski
What about cython?
...
It looks like it will satisfy both of the requirements that Collin mentioned:
1. This is a technology that can be used right now.
2. It offers a serious increase in productivity.
Maybe for Google it makes sense to first prototype in Python, and then transfer critical performance points to Cython, which offers the advantages of pure Python along with close to C efficiency and optimization potential?
Craig citro
I think this is good for writing new Python code. In particular, we use Cython in the Sage library - we write the code and achieve correct work in Python, test it with tests, and then translate the most loaded pieces in Cython. Nevertheless, I think that Collin comments are given in the context of speeding up the work of all existing Python code on Google, without the need to change the source code. In particular, a tool is needed that can be used without worrying about random bugs that may appear in some boundary cases (for example, due to the differences in arithmetic semantics in C and Python).
...
Cython and Unladen Swallow are orthogonal in some ways. In particular, using LLVM (low level virtual machine), Unladen Swallow has prospects in adding runtime optimizations and specializations that Cython can never do.
Collin winter
Acceleration of obvious difficult places is the easiest part of optimization. You encode them in C, use tools like Cython, connect Psyco, etc. We work on accelerating the entire application from beginning to end without the need for special tools, so that performance is more adaptive to code changes, and to accelerate the existing Python language without expanding it. We believe that such extensions and exceptions (meaning type hints in Cython) increase the complexity threshold for transferring code to other developers, increase the number of potentially problematic boundary cases, and increase the training costs required for engineers to write Python applications.
In the correspondence there are many more interesting things, I recommend reading!
(Original article on my blog)
kng
I’ve heard that Google employees don’t recommend using Python for new projects, which seems silly to me, considering how much Python code and support for the Python language itself comes from Google. I started searching for information, but found nothing. Do you know something about this or is it just a rumor?
Collin winder
Even simple common sense limits the applicability of Python when it comes to Google’s scale - it’s not as fast as Java or C ++, work with threads is lame, more memory is used, etc. One of the requirements that we face when designing new systems is “What will we do if the load increases 10 or 100 times? What will we do if the whole planet decides that our new service is awesome? ”Any technology that complicates compliance with this requirement — and I believe that Python falls into this category — must be rejected and even its other usefulness does not play an important role in this case. You have to balance the strengths and weaknesses of Python - your developers can be more productive using Python, but if they have to work hard on scaling under a heavy load, will you be able to get ahead of Python? Etc.
...
Unladen Swallow plans to shift this balance - to make it possible to use Python in a larger number of projects, where it is still irrational to use it now. But it will not be a panacea. Python will still be slower than C or Java, will use more memory and work terribly with threads until someone decides to invest resources in Python in an amount comparable to the resources that Sun invested in the JVM. I hope that attention to the performance of Python on the part of developers will be avalanche-like - the more companies are interested in this, the more resources will be invested, the more graduate students will work on Python (and share the results of their work), etc.
Luis gonzalez
It is clear that Python will be slower than C or Java, but I’m wondering - how fast will Python (in our case, Unladen Swallow) work compared to the V8 js engine? Do you think it will be possible to catch up with the V8? Or do you need a complete rewrite (interpreter) in order to catch up with him?
')
Collin winter
I don't think it is possible to make the CPython implementation as fast as the V8 or SquirrelFish Extreme engines, which are specifically designed for speed. We came up with a number of optimizations that are already very difficult to implement on the basis of CPython and we had to abandon them. Being an open-source project, which enthusiasts are engaged in, CPython dictates other priorities than V8 - CPython places particular emphasis on simplicity, on the idea that a simple slow core is easier to support for people who do it in their spare time than a more complex fast core.
I hope that one of the alternative implementations of Python will ultimately achieve a serious performance gain without reference to C-level backward compatibility (with CPython). We are acting within the boundaries of “What should we do to make things better right now ?”, While PyPy projects work with productivity in perspective “What should we do if we are ready to spend ten years to do everything right?” .
Tom machinski
What about cython?
...
It looks like it will satisfy both of the requirements that Collin mentioned:
1. This is a technology that can be used right now.
2. It offers a serious increase in productivity.
Maybe for Google it makes sense to first prototype in Python, and then transfer critical performance points to Cython, which offers the advantages of pure Python along with close to C efficiency and optimization potential?
Craig citro
I think this is good for writing new Python code. In particular, we use Cython in the Sage library - we write the code and achieve correct work in Python, test it with tests, and then translate the most loaded pieces in Cython. Nevertheless, I think that Collin comments are given in the context of speeding up the work of all existing Python code on Google, without the need to change the source code. In particular, a tool is needed that can be used without worrying about random bugs that may appear in some boundary cases (for example, due to the differences in arithmetic semantics in C and Python).
...
Cython and Unladen Swallow are orthogonal in some ways. In particular, using LLVM (low level virtual machine), Unladen Swallow has prospects in adding runtime optimizations and specializations that Cython can never do.
Collin winter
Acceleration of obvious difficult places is the easiest part of optimization. You encode them in C, use tools like Cython, connect Psyco, etc. We work on accelerating the entire application from beginning to end without the need for special tools, so that performance is more adaptive to code changes, and to accelerate the existing Python language without expanding it. We believe that such extensions and exceptions (meaning type hints in Cython) increase the complexity threshold for transferring code to other developers, increase the number of potentially problematic boundary cases, and increase the training costs required for engineers to write Python applications.
In the correspondence there are many more interesting things, I recommend reading!
(Original article on my blog)
Source: https://habr.com/ru/post/76057/
All Articles