If PyPy is making progress this quickly, apparently matching Unladen Swallow in most cases, then why is Google supporting a separate implementation rather than working on PyPy? Is it just that PyPy wasn't advanced enough when the Unladen Swallow project began, or is it insufficiently compatible with existing Python libraries?
I thought that PyPy is restricted to only a subset of Python called "RPython" (stands for Restricted Python) so it's not fully compatible at all with CPython. Correct me if I'm wrong though as I'm far from being a Python guru.
Remember that these are pypy selected micro benchmarks. Always take a projects marketing and spin with a grain of salt. You don't believe everything microsoft tells you do you? They slightly misrepresent the data shown, by saying that 'PyPy is generally somewhere between the same speed as CPython to 50x faster'. Obviously this is not the case.
Also, they are comparing the unreleased pypy to an old release of cpython. Unladen swallow is aiming at a specific set of tests to speed up.
It's very hard to present comparative benchmarks in a fair way. Making sweeping, and controversial claims does not make them clearer.
They make a false claim that C based code is not needed any more, when C based code is still 5x-50x faster than the fastest of pypy benchmarks.
pypy does not support many of the C optimised python modules, so in real world benchmarks it is way behind, as these C optimised parts are generally in the performance hot spots... where those 5x-50x faster actually does matter.
They do not mention how their CPython was compiled(or even the machine it was run on). Was it 32/64bit? 64bit CPython compiled properly can be easily 4x faster, than a 32bit CPython compiled with i386 optimisation. Especially for these little benchmark type programs.
pypy does not do 64bit well, so would be lots slower than CPython on 64bit for these same benchmarks.
pypy does not seem to have very good IO speed, or threading speed at the moment.
pypy has been given a fair amount of support over the years by google. Remember that pypy was supposed to be done in 2006, so many people gave up on it giving good results in the short term. The pypy project has also been against providing a C API, making the upgrade process very hard for people using C extensions(almost 100% of real world programs).
The unladen swallow project also gives some good ideas to the pypy project, and provides another project to compare against.
Now pypy is making fairly good progress towards performance. It seems it is getting to the stage of speeding up many real world programs. As seen by the benchmarks, it has areas to improve... but is doing very well already.
Lots of these benchmarks, if coded in things like numpy, or using the various multiprocessing libraries available to CPython would be a lot faster than what pypy can do.
For example, take the main loops into numpy... generally 5x-50x speed up over python. Then make the program use threads, or processes, and then you get another 2x-8x speedup. Numpy and other C extensions can easily take advantage of multiple cores and things like SSE, and 64bit optimised libraries. That is 10x-400x faster over all to what a standard CPython program would give you.
Big, real world programs often need 64bit addressing for memory as well. Think about programs using 128GB of memory.
pypy has some really good GC work, where it uses significantly less memory than cpython. This is the major area pypy shines imho.
So those are some of the reasons that pypy can not replace many python programs at the moment. It would take many years to improve pypy to the point where it can replace some programs. Whereas with the approach taken by unladen swallow, the results can already be used.
However, I imagine a time very soon when pypy will be able to replace many cpython run programs.
"However, I imagine a time very soon when pypy will be able to replace many cpython run programs."
Shouldn't that be the goal. Maybe something like numpy could never be fully replaced by pure python code, but it possible json/xml parsing libs and many more could.
It'd be interesting to see a memory usage comparison as well, especially considering that last I checked unladen-swallow's memory usage was less than stellar.
The PyPy JIT is currently less than perfectly optimized for memory usage, and there are a few leaks related to it. However, without the JIT PyPy has a better memory footprint than CPython, so it's likely that the situation will improve markedly.
