Ref: https://mail.python.org/pipermail/python-dev/2016-November/1...
Ref: https://mail.python.org/pipermail/python-dev/2016-November/1...
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.
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.
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%.