Hacker News Reader

Comment by tasubotadas | Hacker News Reader

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

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.)

> 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.

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.

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.

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.

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.

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."

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".

There are a lot of dynamically typed languages that are significantly faster than python. Late binding issues can be effectively worked around.

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?

Doesn't that sort of operation become very fast in JS after a few runs?

Probably most Common Lisp implementations.

You mean concatenating the lists or pairwise addition?

I don't expect the former to be slow in python as it would be a primitive implemented in C (although even a simple lisp interpreter can have an advantage here by just concatenating the conses).

For the latter, any language runtime capable of inference should be able to optimize it.

Racket

I would expect this microbenchpark in particular to be as fast in LuaJIT as it would be in C, without the risk of undefined behavior if the array boundaries are improperly calculated.

LuaJIT.

Assuming you mean pairwise addition, Pharo achieves over twice Python speed, in my laptop.

Python version:

  from random import randrange
  from time import time
  
  def main():
      L = [float(randrange(2**52, 2**53)) for _ in range(20000000)]
      M = [float(randrange(2**52, 2**53)) for _ in range(20000000)]
  
      t0 = time()
      N =  [ x+y for x,y in zip(L, M) ]
      print('Concluded in', round(1000*(time() - t0)), 'millisec.')
  
  main()

Results:

  Python 3.10.5 (main, Jun  9 2022, 00:00:00) [GCC 12.1.1 20220507 (Red Hat 12.1.1-1)] on linux
  Type "help", "copyright", "credits" or "license()" for more information.
  
  ============ RESTART: /run/media/user/KINGSTON/benchmark_doubles.py ============
  Concluded in 1904 millisec.

Pharo 10 version:

  | L M N t0 |
  
  Transcript clear.
  L := (1 to: 2e7) collect: 
   [ :each | (( 2 raisedTo: 52 ) to: ( 2 raisedTo: 53 )) atRandom asFloat ].
  M := (1 to: 2e7) collect: 
   [ :each | (( 2 raisedTo: 52 ) to: ( 2 raisedTo: 53 )) atRandom asFloat ].
  t0 := DateAndTime now.
  M := L with: M collect: [ :x :y | x + y ].
  Transcript
    show: 'Concluded in '
        ,
            ((DateAndTime now - t0) asMilliSeconds asInteger ) asFloat asString
        , ' millisec.';
    cr.

Results:

  Concluded in 914.0 millisec.

Also "what is equals?". That's why people will do:

    def fooer(i: str, strings: list[str]):
        push = str.append
        for s in strings:
            push(i, s)

Apparently this helps the interpreter understand that `append` is not getting overwritten in the global scope elsewhere.

This is one of the most common optimizations in Python, simply because the lookup code for modules/class instances is horrible and slow.

It'd be nice if there were a tool you could run over your code that did this sort of thing. Even if it can technically break shit in absurd cases, I'd totally run it on my code, which isn't absurd.

If it's double, it probably would be addss xmm0, xmm1 :-) (add eax, ebx would be for 32-bit integers.)

You can completely bypass the interpreter by running plain, unannotated Python code through Cython. You get a speedup but it is still slow from manipulating PyObjects and attribute lookups.

>Python being interpreted is the main reason why it’s slow

Common Lisp and Java begs to disagree.

Jvm at least is jitted, not interpreted. Dunno anything about common lisp.

Common Lisp has several compilers generating machine code AOT. See for example http://www.sbcl.org

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).

Javascript spanks other scripting languages.

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.

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.

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.

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.

> 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

I think the way it is usually done is that the JIT assumes, for example after profiling, that an expression has a specific type, generates code according to that assumption and adds strategic guards to check that the assumptions are still valid, with a fall back path to the original unoptimized code. Thanks to the magic of branch prediction the guards have little runtime cost.

Python is harder to optimize than Javascript, as I mentioned. The subject is well explored.

It is true that they haven't tried very hard, or had the resources to until now. But Python will never be as fast as .js due to the reason above.

This is exactly what a lot of the current round of optimization work focuses on. Things like optimistic dispatch on hot loops that fall back to fully dynamic on a miss.

JS is interpreted, and it's much much faster than Python.

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.

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.

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/pl...

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

> other GC languages.

Does not sounds like Rust.

(But other than that I agree with your point.)

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.

Reply on news.ycombinator.com