November 23, 2009 at 01:11Python and speed: Unladen Swallow, PyPy, Cython
Brief translation of the discussion against Recommendation against Python? :
kng
I heard that Google employees are not recommended to use Python for new projects, which seems silly to me, given how much Python code and support for the Python language itself comes from Google. I began to search for information, but did not find anything. 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 the scale of Google - it is not as fast as Java or C ++, working with threads is lame, it consumes more memory, etc. One of the requirements that we encounter 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 - shouldto be rejected and even its other utilities do 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 to a large 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 more 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 horribly 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 the attention to Python performance from the developers will be avalanche-like - the more companies will be interested in this, the more resources will be invested, the more graduate students will work on Python (and post the results of their work), etc.
Luis gonzalez
It's clear that Python will be slower than C or Java, but I wonder how fast Python (in our case, Unladen Swallow) will work compared to the V8 js engine? Do you think that it will be possible to catch up with the V8? Or will a complete rewrite (of the interpreter) be required in order to catch up with it?
Collin winter
I don’t think it’s possible to make the implementation of CPython as fast as the V8 or SquirrelFish Extreme engines, which are specially 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 that 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 work in their spare time than a more complex fast core.
I hope that one of the alternative Python implementations will ultimately achieve significant performance gains without being tied to C-level backward compatibility (with CPython). We act within the boundaries of “What should we do to make things betterright now ? ”, while projects like PyPy are working with productivity in the long run“ What should we do if we are willing to spend ten years to get things right? ”
Tom Machinski
How about Cython?
...
It looks like he 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 performance-critical places to Cython, offering the benefits of pure Python along with near-C performance and optimization potential?
Craig Citro
I think it's good for writingnew Python code. In particular, we use Cython in the Sage library - we write code and get Python to work correctly, put tests on it, and then translate the most loaded pieces into Cython. Nevertheless, I think that Collin's comments are given in the context of speeding up the work of all existing Python code in Google, without the need to change the source. In particular, you need a tool that you can use without worrying about random bugs that may appear in some boundary cases (for example, due to 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 a runtime optimization and specialization that Cython can never do.
Collin winter
Accelerating explicit complex places is the easiest part of optimization. You code them in C, use tools like Cython, connect Psyco, etc. We are working on accelerating the work of the entire application from beginning to end without the need for special tools to make the performance more adaptive to code changes, and on accelerating the existing Python language without expanding it. We believe that such extensions and exceptions (meaning type hints in Cython) increase the threshold of complexity when passing code to other developers, increase the number of potentially problematic boundary cases, and increase the training costs that engineers need to write Python applications.
There is still much interesting in the correspondence, I recommend reading it!
(Original article on my blog)
kng
I heard that Google employees are not recommended to use Python for new projects, which seems silly to me, given how much Python code and support for the Python language itself comes from Google. I began to search for information, but did not find anything. 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 the scale of Google - it is not as fast as Java or C ++, working with threads is lame, it consumes more memory, etc. One of the requirements that we encounter 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 - shouldto be rejected and even its other utilities do 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 to a large 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 more 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 horribly 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 the attention to Python performance from the developers will be avalanche-like - the more companies will be interested in this, the more resources will be invested, the more graduate students will work on Python (and post the results of their work), etc.
Luis gonzalez
It's clear that Python will be slower than C or Java, but I wonder how fast Python (in our case, Unladen Swallow) will work compared to the V8 js engine? Do you think that it will be possible to catch up with the V8? Or will a complete rewrite (of the interpreter) be required in order to catch up with it?
Collin winter
I don’t think it’s possible to make the implementation of CPython as fast as the V8 or SquirrelFish Extreme engines, which are specially 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 that 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 work in their spare time than a more complex fast core.
I hope that one of the alternative Python implementations will ultimately achieve significant performance gains without being tied to C-level backward compatibility (with CPython). We act within the boundaries of “What should we do to make things betterright now ? ”, while projects like PyPy are working with productivity in the long run“ What should we do if we are willing to spend ten years to get things right? ”
Tom Machinski
How about Cython?
...
It looks like he 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 performance-critical places to Cython, offering the benefits of pure Python along with near-C performance and optimization potential?
Craig Citro
I think it's good for writingnew Python code. In particular, we use Cython in the Sage library - we write code and get Python to work correctly, put tests on it, and then translate the most loaded pieces into Cython. Nevertheless, I think that Collin's comments are given in the context of speeding up the work of all existing Python code in Google, without the need to change the source. In particular, you need a tool that you can use without worrying about random bugs that may appear in some boundary cases (for example, due to 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 a runtime optimization and specialization that Cython can never do.
Collin winter
Accelerating explicit complex places is the easiest part of optimization. You code them in C, use tools like Cython, connect Psyco, etc. We are working on accelerating the work of the entire application from beginning to end without the need for special tools to make the performance more adaptive to code changes, and on accelerating the existing Python language without expanding it. We believe that such extensions and exceptions (meaning type hints in Cython) increase the threshold of complexity when passing code to other developers, increase the number of potentially problematic boundary cases, and increase the training costs that engineers need to write Python applications.
There is still much interesting in the correspondence, I recommend reading it!
(Original article on my blog)