Project Aims For 5x Increase In Python Performance 234
cocoanaut writes "A new project launched by Google's Python engineers could make the popular programming language five times faster. The project, which is called Unladen Swallow, seeks to replace the Python interpreter's virtual machine with a new just-in-time (JIT) compilation engine that is built on LLVM. The first milestone release, which was announced at PyCon, already offers a 15-25% performance increase over the standard CPython implementation. The source code is available from the Google Code web site."
This is a very interesting project (Score:5, Interesting)
I read about what they intend to do, and they seem to have quite a few interesting ideas... But there are also major drawbacks:
- No Windows support (apparently a Linux-only VM in the plans)
- No Python 3.0 support
And thus no guarantees most of the work will merge back into CPython.
But competition is good, I can't really see a problem with having an alternative faster Python runtime, even if it's not as compatible as CPython. :)
Re:Kill the GIL! (Score:4, Interesting)
Good luck with that. The last time someone tried that, they slowed Python down by half.
Re:This is a very interesting project (Score:3, Interesting)
I'm not quite sure what benefits this gives that Psyco doesn't already.
Too many levels of translation? (Score:3, Interesting)
It sounds like that they're going to take Python, which is already gets translated to some kind of p-code (right?) and either translate the original Python or the p-code into LLVM code, which is then JIT-compiled to the native architecture.
The translation from Python to LLVM is going to lose some specificity and require that extra code be added to implement whatever needs to be done in Python that isn't trivially implemented by LLVM. Then the LLVM code needs to be compiled to native, introducing yet more "glue" code in the process.
Wouldn't a more direct compile yield a better result?
And don't give me any junk about compiling dynamic languages. LISP and Self are highly dynamic languages, yet they're compiled. If they can be compiled, then so can Python. I mean, the fact that it can be done through multiple levels of translation proves that it can be done, although possibly inefficiently. I just think that a more direct approach would reduce some of the superfluous glue code and a variety of other inefficiencies in translation that result from a loss of knowledge about what the original program was actually trying to implement.
Re:Kill the GIL! (Score:3, Interesting)
Hrmph.
Maybe I'm just drinking kool-aide, but Software Transactional Memory sounds much, much better to me.
The "D" programming language from Digital Mars sounds very interesting, for example.
Re:Kill the GIL! (Score:5, Interesting)
Then you probably want to read: Patrick Logan on why SMT isn't "awesomez" [blogspot.com].
Re:Speed ups for EVE online, perhaps? (Score:1, Interesting)
EVE uses stackless python, which needs a completely different runtime system (libraries, interpreter, etc) than vanilla python.
Re:How fast is five times faster really? (Score:2, Interesting)
If you're talking plain Java vs Python [debian.org], Java looks to be quite a bit faster
The first link above refers to Java used with "Hotspot" and it is really fast. If you select the Java Xint, they are a lot closer although Java is still faster. But that "Hotspot" option looks to me to provide about a 10x speed improvement over plain interpreted Java. http://shootout.alioth.debian.org/u32q/benchmark.php?test=all&lang=javaxint&lang2=java&box=1 [debian.org] If Python were to do something similar, I would expect a significant improvement in its performance too.
Re:Kill the GIL! (Score:3, Interesting)
Or one could keep *A* GIL and largely ignore it. Here's the model I would use.
Separate python into per thread instances yet keep a larger overall memory space to be shared between threads. But, one must explicitly state that they want to go to the global space. That way, when one uses a single threaded application, everything is as it should be, nothing in its way to slow it down. So, those locks won't even get invoked. However, when one is programming a multi-threaded application, then one has the *choice* to either keep them separate or to make them aware of each other and start using the GIL.
With that, I believe that one can largely have his cake and eat it too.
Re:Kill the GIL! (Score:3, Interesting)
Only because Python uses a refcounting garbage collector.
Refcounting itself isn't necessarily the problem; it's using a rudimentary implementation that bogs down. I read a paper a while back where they successfully experimented with a high-tech refcounting gc algorithm specifically because it was amenable to parallel operation on multiple CPUs.
By using a variety of tricks, they were able to avoid actually having to update refcounts for the vast majority of writes (most notably all stack references), and the mutex acquisition was limited to a couple per thread per gc cycle (one dedicated thread did periodic adjustments in a cyclical fashion).
I thought it was pretty interesting because reference counting can have more cache-friendly behavior than copying gc or mark-sweep approaches.
PyV8 offers a 10x performance increase - right now (Score:3, Interesting)
The experimental combination of the Python-to-Javascript compiler, http://pyjs.org/ [pyjs.org] and the Python Bindings to Google's V8 Engine, http://code.google.com/p/pyv8 [google.com] brings a ten times performance increase over standard python, already.
not - "10% now and 5x in the future" - that's a 1000% increase NOW.
When V8 supports the ECMAScript "Harmony" standard, which will include support for basic integer types, then there will be "correct" support in the PyJS + PyV8 combination for numerical types, and the word "experimental" can be dropped.
http://pyjsorg/ [pyjsorg] also includes an experiment showing the bindings of the PyJS compiler with the Python-Spidermonkey project. The spidermonkey JS engine has the advantage of running on generic platforms instead of just ARM and 32-bit x86 platforms, but has the disadvantage of being slightly slower.
Javascript is a _really_ interesting language that makes it in many ways highly suitable as an intermediate compiler language for compiling dynamic languages as Ruby and Python.