I spent about one week implementing PyPy's storage strategies in my language's collection types. When I finished the vector type modifications, I benchmarked it and saw the ~10% speed up claimed in the paper¹. The catch is performance increased only for unusually large vectors, like thousands of elements. Small vectors were actually slowed down by about the same amount. For some reason I decided to press on and implement it on my hash table type too which is used everywhere. That slowed the entire interpreter down by nearly 20%. The branch is still sitting there, unmerged.
I can't imagine how difficult it must have been for these guys to write a compiler and succeed at speeding up the Python interpreter.
¹ https://tratt.net/laurie/research/pubs/html/bolz_diekmann_tr...
[1]: https://en.wikipedia.org/wiki/Benevolent_dictator_for_life
the irony :/
Test your packages on Pypy, people.
I guess that now the GIL is going away, pypy will become better at handling packages with native code like numpy
Most c extension modules should work in pypy, there's just a performance hit depending on how they're built (cffi is the most compatible).
https://doc.pypy.org/en/latest/faq.html#do-c-extension-modul...
People wanting to use Pypy usually do so because they want better performance. Having a performance hit while using pypy is disconcerting.
I was speculating that in the future, C extensions in pypy would be faster, but I now see that the GIL is actually unrelated to this performance hit. Anyway it's really a pity.
Please do not phrase that as a failure of Pypy. That is so weird.
That said, it has happened often enough I'm cautious about where I use it. It would suck to be dependent on pypy's excellent performance, and then find I can't do something due to library incompatibility.
Now, a lot of C packages work - and where they don't it's worth raising bugs: with PyPy, but also in the downstream program - occasionally they can use something else if it looks like the fix will take a while.
It's goal is to create as many 'return' instructions as it can decide to.
GIL is merely a CPython problem but synchronization can also be a compilation problem.
Ref: https://mail.python.org/pipermail/python-dev/2016-November/1...
Even in other contexts it can be ambiguous.
Yesterday I drove 60mph, today I drove 50% faster.
Yesterday I got there in 1 hour, today I got there 50% faster.
It's not really possible to tell them apart without looking at the numbers.
If you've rewritten something to better use cachelines, removed saturating memory bandwidth, etc then sure you've increased The computation rate. But that's rarely how these language specific optimizations occur.
21%, not 19%.
It is 1.1 * 1.1 = 1.21
You are right in the opposite direction. If it got 10% slower, then it is 0.9 * 0.9 = 0.81 = 19% slower
When you say something is 10% faster, what you mean is it took 10% less time to finish. So 19% is correct.
Unless one uses a bit more esoteric definition of speed, in which a 50 percent of car speed increase, makes it go from 100 km/h to 200 km/h, such that it arrives in half the time.
Where is the evidence that before python 3 was significantly slower than 2.7 before 3.6?
Interestingly they singled out pyaes as one of the worst offenders. I've also written a pure-python AES implementation, one that deliberately takes advantage of the "long" integer representation, and it beats pyaes by about 2000%.
No one is disappointed by V8's 6-8% improvement with Maglev. [1]
Because V8 is (for a scripting language) insanely fast.
And Python is not, unfortunately.
In many cases, Node.js is an order of magnitude faster than CPython.
(Acknowledged: You could write your Python in C.)
(Acknowledged: PyPy exists.)
FWIW, the most recent changelog is at https://docs.python.org/3.13/whatsnew/3.13.html
x ln 0.9 = ln 0.5
x = ln 0.5 / ln 0.9
x = 6.5788
So decreasing runtime by 10% 6.5788 times results in the code running in half the original time.