5 ms·

Because it took 10 years to have Python 3 being as fast as Python 2 while being more strict. 2-9% means it will be another 10 years to have Python 3 being signi

Because it took 10 years to have Python 3 being as fast as Python 2 while being more strict. 2-9% means it will be another 10 years to have Python 3 being significantly faster. Ref: https://mail.python.org/pipermail/python-dev/2016-November/146800.html https://mail.python.org/pipermail/python-dev/2016-November/1...

cycomanic 3y ago
The reference really doesn't say what you posted. It just says that python 3.6 was up to 45% faster than 2.7 on some benchmarks and up to 54% slower on some others (which the author of the suite considered largely unrealistic). Where is the evidence that before python 3 was significantly slower than 2.7 before 3.6?
chalst 3y ago
5.5% compounded over 5 years is a bit over 30%: not a huge amount but an easily noticeable speed-up. What were you thinking of when you typed “significantly faster”?
- aktenlage 3y ago
  Compunding a decrease works differently than an increase. If something gets 10% faster twice it actually got 19% faster. In other words, the runtime is 90% of 90%, i.e. 81%.
  - BeetleB 3y ago
    > If something gets 10% faster twice it actually got 19% faster 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
    - readams 3y ago
      It's easy to see there must be something wrong with this since if you get 10% faster 8 times, we can be sure that this doesn't mean you're 114% faster (1.1^8 = 2.14). You can't get more than 100% faster! When you say something is 10% faster, what you mean is it took 10% less time to finish. So 19% is correct.
      - nuancebydefault 3y ago
        100 percent faster means doubling the speed,just like a 100 percent salary increase means doubling the salary, or 100 percent car speed increase means doubling its speed. 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.
  - ummonk 3y ago
    Not if “faster” refers to computation rate rather than runtime, in which case it becomes 100/81 i.e. 23% faster.
    - moomin 3y ago
      Yes, but I’ve literally never heard anyone say that.
      - kaashif 3y ago
        It's not really possible to tell if someone saying "50% faster" means a 50% speed increase or a 50% time decrease. 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.
      - ummonk 3y ago
        You've never seen anyone say "x% faster" where x is a number larger than 100? I find that hard to believe.
        squeaky-clean 3y ago
        Not for a programming language because it's extremely rare for the computation rate to increase, rather than the work being done to compute something decrease. 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.
      - chalst 3y ago
        I have, in technical descriptions of compilers.
  - chalst 3y ago
    In a certain sense, decreases are reciprocals of increases. You can calculate the reciprocal of each “faster”, or you can work with the figures as given and what you want is the reciprocal of the final result. This follows from the elementary fact that division is the same as multiplication by the reciprocal and we are only treating multiplication and division.
bilsbie 3y ago
What! Why? (I couldn’t figure it out from your link)
- Retr0id 3y ago
  The link seems fairly clear to me - One explanation given is that python3 represents all integers in a "long" type, whereas python2 defaulted to small ints. This gave (gives?) python2 an advantage on tasks involving manipulating lots of small integers. Most real-world python code isn't like this, though. 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%.
paulddraper 3y ago
That link is pretty clear that it's a non-realistic benchmark that results in a Python 3 slowdown. (And there are many benchmarks that are faster in Python 3.)

cycomanic 3y ago

The reference really doesn't say what you posted. It just says that python 3.6 was up to 45% faster than 2.7 on some benchmarks and up to 54% slower on some others (which the author of the suite considered largely unrealistic). Where is the evidence that before python 3 was significantly slower than 2.7 before 3.6?

chalst 3y ago

5.5% compounded over 5 years is a bit over 30%: not a huge amount but an easily noticeable speed-up. What were you thinking of when you typed “significantly faster”?

aktenlage 3y ago
Compunding a decrease works differently than an increase. If something gets 10% faster twice it actually got 19% faster. In other words, the runtime is 90% of 90%, i.e. 81%.
- BeetleB 3y ago
  > If something gets 10% faster twice it actually got 19% faster 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
  - readams 3y ago
    It's easy to see there must be something wrong with this since if you get 10% faster 8 times, we can be sure that this doesn't mean you're 114% faster (1.1^8 = 2.14). You can't get more than 100% faster! When you say something is 10% faster, what you mean is it took 10% less time to finish. So 19% is correct.
    - nuancebydefault 3y ago
      100 percent faster means doubling the speed,just like a 100 percent salary increase means doubling the salary, or 100 percent car speed increase means doubling its speed. 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.
- ummonk 3y ago
  Not if “faster” refers to computation rate rather than runtime, in which case it becomes 100/81 i.e. 23% faster.
  - moomin 3y ago
    Yes, but I’ve literally never heard anyone say that.
    - kaashif 3y ago
      It's not really possible to tell if someone saying "50% faster" means a 50% speed increase or a 50% time decrease. 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.
    - ummonk 3y ago
      You've never seen anyone say "x% faster" where x is a number larger than 100? I find that hard to believe.
      - squeaky-clean 3y ago
        Not for a programming language because it's extremely rare for the computation rate to increase, rather than the work being done to compute something decrease. 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.
    - chalst 3y ago
      I have, in technical descriptions of compilers.
- chalst 3y ago
  In a certain sense, decreases are reciprocals of increases. You can calculate the reciprocal of each “faster”, or you can work with the figures as given and what you want is the reciprocal of the final result. This follows from the elementary fact that division is the same as multiplication by the reciprocal and we are only treating multiplication and division.

bilsbie 3y ago

What! Why? (I couldn’t figure it out from your link)

Retr0id 3y ago
The link seems fairly clear to me - One explanation given is that python3 represents all integers in a "long" type, whereas python2 defaulted to small ints. This gave (gives?) python2 an advantage on tasks involving manipulating lots of small integers. Most real-world python code isn't like this, though. 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%.

paulddraper 3y ago

That link is pretty clear that it's a non-realistic benchmark that results in a Python 3 slowdown. (And there are many benchmarks that are faster in Python 3.)