PyPy was never able to get fast enough to replace CPython in spite of its lack of compatible C API. CPython is trying to move fast without breaking C API, and 2--9% improvement is in fact very encouraging for that and other reasons (see my other comment).
PyPy to me looks like a great effort and a technological tour de force. But I wish they would talk _more_ about why and when PyPy will be _slower_ than CPython on their site . Here is why.
I tried to run some of my scripts on PyPy and performance was invariably worse (about 50% worse). And my first reaction was: PyPy is not delivering on its promises. Only later, on some forum I read that PyPy does not perform well on large dictionaries (and this is essentially what I do in my scripts). Have I known it in advance, my first impression of PyPy would be much better.
I sincerely doubt that. PyPy is advertised as being about 7x as fast ad CPython and yet it also has incredibly low adoption rates because of potential breakage and incompatibilities.
I'm not sure why you think pypy is slower than cpython "at pretty much everything" after looking at this site. Out of the 21 benchmarks given, 10 are 2x or more faster than cpython, 10 are between 2x faster and 2x slower and only 1 is more than 2x slower.
>I would certainly prefer it if PyPy was 100% compatible with the CPython C API even if it was at 80% (maybe even 60%) of the CPython C API speed because then I don't even have to think. I'd be using PyPy because it's faster overall and I can do the analyses I want faster.
While part of me agrees with this, if PyPy starts sacrificing performance for CPython compatibility then pretty soon it'll degenerate into CPython.
> PyPy is still significantly faster than CPython while (afaik) allowing that sort of stuff to go on
First of all that's only true when it managed to jit the code, secondly only until you try to do any of those slow things. For instance the C ABI emulation they have both cannot support all of CPython and wrecks performance. The same is true if you try to do fancy things with sys._getframe which a lot of code does in the wild (eg: all of logging).
In addition PyPy has to do a lot of special casing for all the crazy things CPython does. I recommend looking into the amount of engineering that went into it.
PyPy is only twice as slow as v8 and is about an order of magnitude faster than CPython. It is quite an achievement. I would be very happy if CPython could get this performance but I doubt.
I recall that the main issue with PyPy is that it doesn't have as good interop with C and a lot of CPython codes just call C code and hence is difficult to widely adopt given the amount of reliance on CPython.
Performance isn't a quality that is either present or not present, it's a quantity you can measure with a number as you did. It's true that pypy is much faster than CPython, but it's also true that C++ is much faster than pypy. Cpython is normally about 2 orders of magnitude slower than C++ on computationally intensive workloads, and if pypy get that down to a single order of magnitude that's great... but not enough here.
That's a whole other issue. PyPy and CPython have conflicting aims, which is partly why it never replaced CPython as the defacto default Python runtime. Also, PyPy is much slower for stuff that's only going to run for a short time. Still, many of the lessons learned in PyPy can be used to improve CPython performance.
I don't know much about the other ones, but I think you'd have to say PyPy has been a success. Although to be honest, I don't know why it would be better to modify CPython vs. just using PyPy -- the JIT speedup does come with some tradeoffs (memory usage, warmup times), so it seems better just to leave that decision up to the user?
reply