How Fast is Python 3.15?

(blog.miguelgrinberg.com)

33 points | by Qem 4 hours ago

7 comments

  • DroneBetter 1 hour ago
    you should include a faster version of the fibonacci function with exponentiation by squaring

      def fibonacci(k):
        a,b=(0,1)
        for i in range(k.bit_length()-1,-1,-1):
          d=a**2
          c=2*a*b-d
          d+=b**2
          (a,b)=(d,c+d) if k>>i&1 else (c,d)
        return a
    
    see https://oeis.org/wiki/User:Natalia_L._Skirrow/linear_recurre... (warning: old and bad and in need of revision), https://github.com/sympy/sympy/pull/30452 and https://github.com/sympy/sympy/pull/30541 for details of how to make similarly fast programs for arbitrary linear-recurrent sequences.

    you can also encode polynomials into integers; see https://mathstodon.xyz/@peterluschny/116320199782572958 and the following prog from https://codegolf.stackexchange.com/a/279771

      lambda n:pow(p:=2<<n,n,p*p+~p)//p
    
    both of these would be more intensive on the arithmetic side rather than control flow

    also you could at least wrap the existing one in a `functools.cache`

  • makaimc 3 hours ago
    35 years on since the first public Python release and there's still so much room for improvement in its performance. These tests by Miguel are a useful quick check on that progress in 3.15 even if as he admits it's impossible to get "an objective and universal measure of the performance of a programming language".
  • brianwawok 2 hours ago
    So Claude can convert python code bases to rust or golang, and give you an easy 10x speed boost. Much better than waiting for Python performance to improve
    • nomel 1 minute ago
      Yeah, none of these tight loop benchmark tasks should be happening in python, which is why you won't see anywhere NEAR this kind of speedup with "normal" python code, that makes any attempt to not spend too much time in python.
    • ks2048 2 hours ago
      For a lot of scripts (think replacement to bash scripts - perhaps even one-offs), Python will save time over rust compilation times.
      • nazcan 2 hours ago
        Golang it is then! I'm really enjoying the fast compile time compared to C++...
        • skrtskrt 1 hour ago
          And packaging + distribution is ridiculously easy.

          We are moving every script we can to Go. Compared to bash it's a no-brainer, every dev can understand it, it has approximately .0000000000001% of the possible footguns, a great debugger, etc.

      • cogman10 1 hour ago
        For one offs, sure. But once you get to a script executed multiple times it doesn't take very long before you have payed off the rust compile time. Especially if it is fairly simple (as in, you can do everything with just rust std lib and not a bunch of rust libs).

        Almost all the rust compilation times come from needing to build the supporting libs. For simple scripts, it's very possible to get away with just using the std lib.

        • UnlockedSecrets 1 hour ago
          At the same time, If a python script can be thrown together in 20 minutes, and it will execute hundreds of times at most..... Who really cares if it takes 25 seconds to execute, or 2 minutes as long as it accomplishes all it is intended to do?
          • cogman10 1 hour ago
            In my opinion, what is pretty typical a script will be executed never, once, or thousands of times.

            If you are at the point of doing multiple executions, you are probably at the point where converting your script to rust would end up saving time/power. Maybe not all the time (like a manually executed script), but not infrequently.

      • loeg 2 hours ago
        Non-optimized builds can be pretty quick, although I guess you're always paying for borrow checking.
    • tclancy 1 hour ago
      Why not convert to assembly?
    • sgarland 2 hours ago
      There is a benefit in being able to read and understand your code. If you’re most proficient in Python, it’s reasonable to want to stay there, perhaps looking to PyPy.

      Also, of course, the majority of SaaS apps (perhaps most apps in general?) are not compute-bound, so gains from performance alone shouldn’t be the only metric.

      My current job has a mix of Python and Go. Personally, I dislike Go. I don’t like its syntax, I don’t like its utter lack of formatting standards (gofmt is not a standard; also it sets tabs - ugh), I don’t like its insistence on static linking, and I don’t like how people claim it’s a great scripting language when you can’t just run a file on its own (and its stdlib is weak sauce compared to Python).

      • winrid 25 minutes ago
        Rust is nice to read because you can see from a function signature what it mutates

        If you write slow rust, it's very easy to read, and still plenty fast.

      • killingtime74 42 minutes ago
        I can read rust much easier than go at least. If the Python doesn't have types then it's about even as well.
      • loeg 2 hours ago
        Of course, Claude understands Rust, too.
  • rurban 2 hours ago
    2 benchmarks only? A very broad sense of coverage
  • bjourne 1 hour ago
    My pet peeve are numbers with too many decimals. If you only run a benchmark three times and take the arithmetic mean you don't have five or more significant digits. At best, you have two. And for benchmarking the geometric mean is a far superior mean.
    • jrk 1 hour ago
      For averaging multiple different benchmarks, the geometric mean makes sense. For removing measurement noise from a single benchmark, min or median is usually the right statistic.
  • actionfromafar 3 hours ago