5 ms·

Cool improvement but changes very little when Python is x100 times slower than other GC languages.

woodruffw 4y ago
This is probably the wrong comparison to make: Python is two orders of magnitude slower than compiled GC languages, but it's in the same order of magnitude as most other interpreted GC languages. (It actually changes a whole lot, because there's a whole lot of code already out there written in Python. 25% faster is still 25% faster, even if the code would have been 100x faster to begin with in another language.)
- TuringTest 4y ago
  > 25% faster is still 25% faster, even if the code would have been 100x faster to begin with in another language.) And that's even assuming that the code would have existed at all in another language. The thing about interpreted GC languages is that the iterative loop of creation is much more agile, easier to start with and easier to prototype in than a compiled, strictly typed language.
  - z3c0 4y ago
    I think this is the best explanation for its popularity. Sure, it runs slow, but it's very fast to write. The latter is usually more important in the world of business, for better or worse.
    - jonnycomputer 4y ago
      The majority of code I write, the efficiency of the code is mostly a secondary concern; it will be run only a few times at most, and the fact that its a a few 1000 times slower than something written in C or C++ means waiting a few more seconds (at most) for my results. Most of my time spent is writing it, not running it.
    - toyg 4y ago
      Not just in the world of business - a lot of developers play with these things in their spare time before promoting them to production tech; if it takes ages to write a silly mp3 player or some other hobby project, they'll use something else instead.
- speedgoose 4y ago
  Python being interpreted is the main reason why it’s slow, but not the excuse to not compare it to similar and faster programming languages.
  - woodruffw 4y ago
    You're welcome to make the comparison. I'm just pointing out that it's a sort of category error, beyond the relatively bland observation of "interpretation is slow."
  - deleted 4y ago
    [deleted]
  - AlexTWithBeard 4y ago
    One of the biggest contributors in Python's (lack of) speed is dynamic typing. While a jump is a jump and an assignment is an assignment, an addition is more like "hmm... what is a left operand... is it double? what is a right operand? wow, it's also a double! okay, cpu add eax, ebx".
    - deleted 4y ago
      [deleted]
    - gpderetta 4y ago
      There are a lot of dynamically typed languages that are significantly faster than python. Late binding issues can be effectively worked around.
      - AlexTWithBeard 4y ago
        Do you have an example of a dynamically typed language where, say, addition of two lists of doubles would be significantly faster than in Python?
        bobbylarrybobby 4y ago
        Doesn't that sort of operation become very fast in JS after a few runs?
- Wohlf 4y ago
  I thought Python was slower than many other interpreted languages but looking at some benchmark it turns out I was wrong. It's about on par with Ruby, only Lua and JIT compiled runtimes beat it (for very understandable reasons).
  - cutler 4y ago
    Javascript spanks other scripting languages.
- ianbicking 4y ago
  Python is compiled to a VM (that is CPython). The semantics and implementation of the VM haven't prioritized performance as much as some other systems. Here we're seeing improvements in the implementation. But the semantics will be the hard part, as those semantics limit the performance. For instance "a + b" is (I believe) compiled into bytecodes that pretty much follow the expression. But the implementation of "add" has to take into account __add__() and the possible function calls and exceptions and return types that implies. If you compiled that all down to machine code (which people have done) you'd still have to run all that code to check types and the existence of methods and so on.
  - coliveira 4y ago
    Dynamic languages like Javascript have solved this problem by essentially caching the resolution of a particular expression that is executed very often. I don't see why this cannot be done in Python.
    - mixmastamyk 4y ago
      The expressions are dynamic, so they have to be evaluated every time. Python is excessively dynamic, so it can't (conventionally) be sped up as easily as many other languages unfortunately. Finally some folks are being paid and allowed to be working on it.
      - coliveira 4y ago
        I don't buy this. There are many contexts in which a smart JIT compiler can detect that an expression cannot be modified. Especially since, due to the GIL, python code is mostly non-threaded. They just didn't spend enough time to do the hard work that people spent on Javascript.
        dbrueck 4y ago
        > can detect that an expression cannot be modified Can you give some examples? I use Python a lot and it's absurdly dynamic. I've sometimes wondered if there'd be some way to let me as the programmer say "dynamicness of this module is only 9 instead of the default 11" but I'm skeptical of a tool's ability to reliably deduce things. Here's just one example: a = 0 for i in range(10): a += 1 log('A is', a) In most languages you could do static analysis to determine that 'a' is an int, and do all sorts of optimizations. In Python, you could safely deduce that 99.9999% of the time it's an int, but you couldn't guarantee it because technically the 'log' function could randomly be really subversive and reach into the calling scope and remap 'a' to point to some other int-like object that behaves differently. Would "legitimate" code do that? Of course not, but it's technically legal Python and just one example of the crazy level of dynamic-ness, and a tool that automatically optimizes things would need to preserve the correctness of the program. EDIT: tried to fix code formatting
- bufferoverflow 4y ago
  JS is interpreted, and it's much much faster than Python.
unethical_ban 4y ago
It changes a lot when that doesn't matter because an org only uses python for their ops automation. Doing side by side comparisons between golang and python on Lambda last year, we halved the total execution time one a relatively simple script. Factor of 100, I assume, is an absolute best case.
dagmx 4y ago
I feel this is a bit nihilistic. Python is used in so many different areas, in some very critical roles. Even a small speedup is going to be a significant improvement in metrics like energy use. The pragmatic reality is that very few people are going to rewrite their Python code that works but is slow into a compiled language when speed of execution is trumped by ease of development and ecosystem.
fmakunbound 4y ago
This was my immediate thought when I looked at the numbers, but I didn't want to be "that guy". I think if all you ever work in is Python, it's still nice even if it is a tiny improvement.
- cglace 4y ago
  The goal with faster cpython is for small compounding improvements with each point release[0]. So in the end it should be much more than a tiny improvement. [0] https://github.com/markshannon/faster-cpython/blob/master/plan.md https://github.com/markshannon/faster-cpython/blob/master/pl...
323 4y ago
It will still improve the data center power bill of thousands of companies, while saying to them "just Rewrite it in Rust" will not.
- timeon 4y ago
  > other GC languages. Does not sounds like Rust. (But other than that I agree with your point.)

This is probably the wrong comparison to make: Python is two orders of magnitude slower than compiled GC languages, but it's in the same order of magnitude as most other interpreted GC languages. (It actually changes a whole lot, because there's a whole lot of code already out there written in Python. 25% faster is still 25% faster, even if the code would have been 100x faster to begin with in another language.)

TuringTest 4y ago
> 25% faster is still 25% faster, even if the code would have been 100x faster to begin with in another language.) And that's even assuming that the code would have existed at all in another language. The thing about interpreted GC languages is that the iterative loop of creation is much more agile, easier to start with and easier to prototype in than a compiled, strictly typed language.
- z3c0 4y ago
  I think this is the best explanation for its popularity. Sure, it runs slow, but it's very fast to write. The latter is usually more important in the world of business, for better or worse.
  - jonnycomputer 4y ago
    The majority of code I write, the efficiency of the code is mostly a secondary concern; it will be run only a few times at most, and the fact that its a a few 1000 times slower than something written in C or C++ means waiting a few more seconds (at most) for my results. Most of my time spent is writing it, not running it.
  - toyg 4y ago
    Not just in the world of business - a lot of developers play with these things in their spare time before promoting them to production tech; if it takes ages to write a silly mp3 player or some other hobby project, they'll use something else instead.
speedgoose 4y ago
Python being interpreted is the main reason why it’s slow, but not the excuse to not compare it to similar and faster programming languages.
- woodruffw 4y ago
  You're welcome to make the comparison. I'm just pointing out that it's a sort of category error, beyond the relatively bland observation of "interpretation is slow."
- deleted 4y ago
  [deleted]
- AlexTWithBeard 4y ago
  One of the biggest contributors in Python's (lack of) speed is dynamic typing. While a jump is a jump and an assignment is an assignment, an addition is more like "hmm... what is a left operand... is it double? what is a right operand? wow, it's also a double! okay, cpu add eax, ebx".
  - deleted 4y ago
    [deleted]
  - gpderetta 4y ago
    There are a lot of dynamically typed languages that are significantly faster than python. Late binding issues can be effectively worked around.
    - AlexTWithBeard 4y ago
      Do you have an example of a dynamically typed language where, say, addition of two lists of doubles would be significantly faster than in Python?
      - bobbylarrybobby 4y ago
        Doesn't that sort of operation become very fast in JS after a few runs?
Wohlf 4y ago
I thought Python was slower than many other interpreted languages but looking at some benchmark it turns out I was wrong. It's about on par with Ruby, only Lua and JIT compiled runtimes beat it (for very understandable reasons).
- cutler 4y ago
  Javascript spanks other scripting languages.
ianbicking 4y ago
Python is compiled to a VM (that is CPython). The semantics and implementation of the VM haven't prioritized performance as much as some other systems. Here we're seeing improvements in the implementation. But the semantics will be the hard part, as those semantics limit the performance. For instance "a + b" is (I believe) compiled into bytecodes that pretty much follow the expression. But the implementation of "add" has to take into account __add__() and the possible function calls and exceptions and return types that implies. If you compiled that all down to machine code (which people have done) you'd still have to run all that code to check types and the existence of methods and so on.
- coliveira 4y ago
  Dynamic languages like Javascript have solved this problem by essentially caching the resolution of a particular expression that is executed very often. I don't see why this cannot be done in Python.
  - mixmastamyk 4y ago
    The expressions are dynamic, so they have to be evaluated every time. Python is excessively dynamic, so it can't (conventionally) be sped up as easily as many other languages unfortunately. Finally some folks are being paid and allowed to be working on it.
    - coliveira 4y ago
      I don't buy this. There are many contexts in which a smart JIT compiler can detect that an expression cannot be modified. Especially since, due to the GIL, python code is mostly non-threaded. They just didn't spend enough time to do the hard work that people spent on Javascript.
      - dbrueck 4y ago
        > can detect that an expression cannot be modified Can you give some examples? I use Python a lot and it's absurdly dynamic. I've sometimes wondered if there'd be some way to let me as the programmer say "dynamicness of this module is only 9 instead of the default 11" but I'm skeptical of a tool's ability to reliably deduce things. Here's just one example: a = 0 for i in range(10): a += 1 log('A is', a) In most languages you could do static analysis to determine that 'a' is an int, and do all sorts of optimizations. In Python, you could safely deduce that 99.9999% of the time it's an int, but you couldn't guarantee it because technically the 'log' function could randomly be really subversive and reach into the calling scope and remap 'a' to point to some other int-like object that behaves differently. Would "legitimate" code do that? Of course not, but it's technically legal Python and just one example of the crazy level of dynamic-ness, and a tool that automatically optimizes things would need to preserve the correctness of the program. EDIT: tried to fix code formatting
bufferoverflow 4y ago
JS is interpreted, and it's much much faster than Python.

unethical_ban 4y ago

It changes a lot when that doesn't matter because an org only uses python for their ops automation. Doing side by side comparisons between golang and python on Lambda last year, we halved the total execution time one a relatively simple script. Factor of 100, I assume, is an absolute best case.

dagmx 4y ago

I feel this is a bit nihilistic. Python is used in so many different areas, in some very critical roles. Even a small speedup is going to be a significant improvement in metrics like energy use. The pragmatic reality is that very few people are going to rewrite their Python code that works but is slow into a compiled language when speed of execution is trumped by ease of development and ecosystem.

fmakunbound 4y ago

This was my immediate thought when I looked at the numbers, but I didn't want to be "that guy". I think if all you ever work in is Python, it's still nice even if it is a tiny improvement.

cglace 4y ago
The goal with faster cpython is for small compounding improvements with each point release[0]. So in the end it should be much more than a tiny improvement. [0] https://github.com/markshannon/faster-cpython/blob/master/plan.md https://github.com/markshannon/faster-cpython/blob/master/pl...

323 4y ago

It will still improve the data center power bill of thousands of companies, while saying to them "just Rewrite it in Rust" will not.

timeon 4y ago
> other GC languages. Does not sounds like Rust. (But other than that I agree with your point.)