6 ms·

It's interesting to see these 2-9% improvements from version to version. They are always talked about with disappointment, as if they are too small, but they al

It's interesting to see these 2-9% improvements from version to version. They are always talked about with disappointment, as if they are too small, but they also keep coming, with each version being faster than the previous one. I prefer a steady 10% per version over breaking things because you are hoping for bigger numbers. Those percentages add up!

bilsbie 3y ago
Someone please compare 3.13 to 2.3! I’d love to see how far we’ve come.
- chalst 3y ago
  Good idea! It can be done fairly easily by people who are good with changelogs. FWIW, the most recent changelog is at https://docs.python.org/3.13/whatsnew/3.13.html https://docs.python.org/3.13/whatsnew/3.13.html
  - ska 3y ago
    I suspect parent meant a performance comparison...
frou_dh 3y ago
I think it's more an issue of framing sometimes causing confusion, i.e. the ultimate trajectory is probably "crushingly slow → slow" rather than fastness coming in to it. (h/t https://news.ycombinator.com/item?id=35906158 https://news.ycombinator.com/item?id=35906158)
technocratius 3y ago
Well I think they even multiply, making it even better news!
- chmod775 3y ago
  I'd rather they add up. Minus -5% runtime there, another -5% there... Soon enough, python will be so fast my scripts terminate before I even run them, allowing me to send messages to my past self.
- Qem 3y ago
  log(2)÷log(1.1) ~= 7.27, so in principle sustained 10% improvements could double performance every 7 releases. But at some point we're bound to face diminishing returns.
  - hughdbrown 3y ago
    .9 * x = 0.5 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.
    - Dylan16807 3y ago
      I think their number is the right one. Ten percent faster is not a ten percent decrease in runtime, it's about a nine percent decrease.
hartator 3y ago
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.
nextaccountic 3y ago
This is happening mostly because Guido left, right? The take that CPython should be a reference implementation and thus slow always aggravated me (because, see, no other implementation can compete because every package depends on CPython kirks, in such a way that we're now removing the GIL of CPython rather than migrating to Pypy for example)
- onesphere 3y ago
  As a compiler, python is an optimized (C/kernel) implementation of parse generation. JIT (PyPy) is a method that parses a 'trace' variation of grammar instead of syntax, where the optimizer compiles source objects that are not limited to python code. 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.
- bb88 3y ago
  Guido is still involved, but he's no longer the BDFL.
  - Cupprum 3y ago
    Just to clarify BDFL. [1]: https://en.wikipedia.org/wiki/Benevolent_dictator_for_life https://en.wikipedia.org/wiki/Benevolent_dictator_for_life
  - paulddraper 3y ago
    > no longer the BDFL the irony :/
    - earthboundkid 3y ago
      They should have ceremonially defenestrated him from a ground floor window.
    - dragonwriter 3y ago
      “Dictator” means you get to arbitrarily change the rules. In his case, to end his own term early.
matheusmoreira 3y ago
I envy these small and steady improvements!! 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_tratt__storage_strategies_for_collections_in_dynamically_typed_languages/ https://tratt.net/laurie/research/pubs/html/bolz_diekmann_tr...
deleted 3y ago
[deleted]
paulddraper 3y ago
It's not the size of the improvement that's regrettable, it's the absolute performance after the improvement. 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. [1] https://v8.dev/blog/holiday-season-2023 https://v8.dev/blog/holiday-season-2023
- rattray 3y ago
  What are some good stats/benchmarks on the rough order of magnitude of python vs js perf these days?
  - paulddraper 3y ago
    https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/python.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... In many cases, Node.js is an order of magnitude faster than CPython. (Acknowledged: You could write your Python in C.) (Acknowledged: PyPy exists.)

bilsbie 3y ago

Someone please compare 3.13 to 2.3! I’d love to see how far we’ve come.

chalst 3y ago
Good idea! It can be done fairly easily by people who are good with changelogs. FWIW, the most recent changelog is at https://docs.python.org/3.13/whatsnew/3.13.html https://docs.python.org/3.13/whatsnew/3.13.html
- ska 3y ago
  I suspect parent meant a performance comparison...

frou_dh 3y ago

I think it's more an issue of framing sometimes causing confusion, i.e. the ultimate trajectory is probably "crushingly slow → slow" rather than fastness coming in to it. (h/t https://news.ycombinator.com/item?id=35906158 https://news.ycombinator.com/item?id=35906158)

technocratius 3y ago

Well I think they even multiply, making it even better news!

chmod775 3y ago
I'd rather they add up. Minus -5% runtime there, another -5% there... Soon enough, python will be so fast my scripts terminate before I even run them, allowing me to send messages to my past self.
Qem 3y ago
log(2)÷log(1.1) ~= 7.27, so in principle sustained 10% improvements could double performance every 7 releases. But at some point we're bound to face diminishing returns.
- hughdbrown 3y ago
  .9 * x = 0.5 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.
  - Dylan16807 3y ago
    I think their number is the right one. Ten percent faster is not a ten percent decrease in runtime, it's about a nine percent decrease.

hartator 3y ago

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.

nextaccountic 3y ago

This is happening mostly because Guido left, right? The take that CPython should be a reference implementation and thus slow always aggravated me (because, see, no other implementation can compete because every package depends on CPython kirks, in such a way that we're now removing the GIL of CPython rather than migrating to Pypy for example)

onesphere 3y ago
As a compiler, python is an optimized (C/kernel) implementation of parse generation. JIT (PyPy) is a method that parses a 'trace' variation of grammar instead of syntax, where the optimizer compiles source objects that are not limited to python code. 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.
bb88 3y ago
Guido is still involved, but he's no longer the BDFL.
- Cupprum 3y ago
  Just to clarify BDFL. [1]: https://en.wikipedia.org/wiki/Benevolent_dictator_for_life https://en.wikipedia.org/wiki/Benevolent_dictator_for_life
- paulddraper 3y ago
  > no longer the BDFL the irony :/
  - earthboundkid 3y ago
    They should have ceremonially defenestrated him from a ground floor window.
  - dragonwriter 3y ago
    “Dictator” means you get to arbitrarily change the rules. In his case, to end his own term early.

matheusmoreira 3y ago

I envy these small and steady improvements!! 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_tratt__storage_strategies_for_collections_in_dynamically_typed_languages/ https://tratt.net/laurie/research/pubs/html/bolz_diekmann_tr...

deleted 3y ago

[deleted]

paulddraper 3y ago

It's not the size of the improvement that's regrettable, it's the absolute performance after the improvement. 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. [1] https://v8.dev/blog/holiday-season-2023 https://v8.dev/blog/holiday-season-2023

rattray 3y ago
What are some good stats/benchmarks on the rough order of magnitude of python vs js perf these days?
- paulddraper 3y ago
  https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/python.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... In many cases, Node.js is an order of magnitude faster than CPython. (Acknowledged: You could write your Python in C.) (Acknowledged: PyPy exists.)