Live data from Hacker News

Python 3.15’s interpreter for Windows x86-64 should hopefully be 15% faster

fidget-spinner.github.io

111–120 of 164 posts

Re: Python 3.15’s interpreter for Windows x86-64 should hopefully be 15% faster

#111
post #82

After years of admonition discouraging me, I’m using Python for a Windows GUI app over my usual C#/MAUI. I’m much more familiar with Python and the whole VS ecosystem is just so heavy for lightweight tasks. I started with tkinter but found it super clunky for interactions I needed heavily, like on field change, but learning QT seemed like more of a lift than I was interested in. (Maybe a skill issue on both fronts?)…

Wait until you see ImGui bindings for Python [1]. It’s immediate mode instead of retained mode like Tkinter/Qt/Wx. It might not be what you’d want if you’re shipping a thick client to customers, but for internal tooling it’s awesome. imgui.text(f"Counter = {counter}") if imgui.button("increment counter"): counter += 1 _, name = imgui.input_text("Your name?", name) imgui.text(f"Hello {name}!") [1] https://github.com/p…

This looks like it would be perfect for the internal user that really just needs to run a shell script with options who’s in the “technical enough to follow instructions faithfully, not technical enough to comfortably/reliably use the command line” demographic.

Re: Python 3.15’s interpreter for Windows x86-64 should hopefully be 15% faster

#112
post #23

Earlier quoted context omitted.

[flagged]

I don't understand why your mind went immediately to pornography. Kind of creepy tbh.

Sigh. Lately I’ve been seeing kids doing this sort of overly-sensitive, bad-intentioned, dishonest pearl-clutching as a weird form of rebellion. This reply has all the linguistic hallmarks of it. Please don’t bring this stuff to HN. It’s ridiculous, and it’s tiring. Nobody is being creepy. Stop trying to stir the pot.

Re: Python 3.15’s interpreter for Windows x86-64 should hopefully be 15% faster

#113
post #110

After years of admonition discouraging me, I’m using Python for a Windows GUI app over my usual C#/MAUI. I’m much more familiar with Python and the whole VS ecosystem is just so heavy for lightweight tasks. I started with tkinter but found it super clunky for interactions I needed heavily, like on field change, but learning QT seemed like more of a lift than I was interested in. (Maybe a skill issue on both fronts?)…

I really like the Python + Qt/pyside combination. I can whip together a rough GUI using QtCreator and then write the app logic in Python super quickly.

I’m sure it would be a goto if I made gui apps more regularly, because it’s clearly the more robust solution. So far wxglade is great for a drag-and-drop designer and the code is just enough closer to the regular Python way of doing things that it’s one less thing to learn.

Re: Python 3.15’s interpreter for Windows x86-64 should hopefully be 15% faster

#114

Earlier quoted context omitted.

The project was first suggested by Mark Shannon. Van Rossum inserted himself into the project. Faster CPython people have been fired by Microsoft last year. Generally not that much has happened in 5 years, sometimes 10-15% improvements are posted that are later offset by bloat. I think the project started in 3.10, so 3.9 is the last version to compare to. The improvements aren't that great, I don't think any other la…

> Generally not that much has happened in 5 years, sometimes 10-15% improvements are posted that are later offset by bloat. Sorry but unless your workload is some C API numpy number cruncher that just does matmuls on the CPU, that's probably false. In 3.11 alone, CPython sped up by around 25% over 3.10 on pyperformance for x86-64 Ubuntu. https://docs.python.org/3/whatsnew/3.11.html#whatsnew311-fas... 3.14 is 35-45% f…

As a data point, running a Python program I've been working on lately, which is near enough entirely Python code, with a bit of I/O: (a prototype for some code I'll ultimately be writing in a lower-level language)

(macOS Ventura, x64)

- System python 3.9.6: 26.80s user 0.27s system 99% cpu 27.285 total

- MacPorts python 3.9.25: 23.83s user 0.32s system 98% cpu 24.396 total

- MacPorts python 3.13.11: 15.17s user 0.28s system 98% cpu 15.675 total

- MacPorts python 3.14.2: 15.31s user 0.32s system 98% cpu 15.893 total

Wish I'd thought to try this test sooner now. (I generally haven't bothered with Python upgrades much, on the basis that the best version will be the one that's easiest to install, or, better yet, is there already. I'm quite used to the language and stdlib as the are, and I've just assumed the performance will still be as limited as it always has been...!)

Re: Python 3.15’s interpreter for Windows x86-64 should hopefully be 15% faster

#115
post #35
post #7

This seems like very low hanging fruit. How is the core loop not already hyper optimized? I'd have expected it to be hand rolled assembly for the major ISAs, with a C backup for less common ones. How much energy has been wasted worldwide because of a relatively unoptimized interpreter?

Probably because anyone concerned with performance wasn’t running workloads on Windows to begin with.

Plenty of DAWs, image editing and video editing being done on Windows.

Re: Python 3.15’s interpreter for Windows x86-64 should hopefully be 15% faster

#117
post #61
post #50

I have quetion - slightly off topic, but related. I was wandering why is pyhton interpreter so much slower than V8 javascript interpreter when both javascript and python are dynamic interpreted languages.

keep in mind that, apart from the money throw at js runtime interpreters by google and others, there is also the fact that python - as a language - is way more "dynamic" than javascript. Even "simple" stuff like field access in python may refer to multiple dynamically-mapped method resolution. Also, the ffi-bindings of python, while offering a way to extend it with libraries written in c/c++/fortran/... , limit how f…

genuinely curious, doesn't JS's proxy objects and prototype-based MRO have a similar performance impact in theory?

Re: Python 3.15’s interpreter for Windows x86-64 should hopefully be 15% faster

#118
post #114

Earlier quoted context omitted.

> Generally not that much has happened in 5 years, sometimes 10-15% improvements are posted that are later offset by bloat. Sorry but unless your workload is some C API numpy number cruncher that just does matmuls on the CPU, that's probably false. In 3.11 alone, CPython sped up by around 25% over 3.10 on pyperformance for x86-64 Ubuntu. https://docs.python.org/3/whatsnew/3.11.html#whatsnew311-fas... 3.14 is 35-45% f…

As a data point, running a Python program I've been working on lately, which is near enough entirely Python code, with a bit of I/O: (a prototype for some code I'll ultimately be writing in a lower-level language) (macOS Ventura, x64) - System python 3.9.6: 26.80s user 0.27s system 99% cpu 27.285 total - MacPorts python 3.9.25: 23.83s user 0.32s system 98% cpu 24.396 total - MacPorts python 3.13.11: 15.17s user 0.28s…

I have a benchmark program I use, a solution to day 5 of the 2017 advent of code, which is all python and negligible I/O. It still runs 8.8x faster on pypy than on python 3.14:

    $ hyperfine "mise exec python@pypy3.11 -- python e.py" "mise exec python@3.9 -- python e.py" "mise exec python@3.11 -- python e.py" "mise exec python@3.14 -- python e.py"
    Benchmark 1: mise exec python@pypy3.11 -- python e.py
      Time (mean ± σ):     148.1 ms ±   1.8 ms    [User: 132.3 ms, System: 17.5 ms]
      Range (min … max):   146.7 ms … 154.7 ms    19 runs

    Benchmark 2: mise exec python@3.9 -- python e.py
      Time (mean ± σ):      1.933 s ±  0.007 s    [User: 1.913 s, System: 0.023 s]
      Range (min … max):    1.925 s …  1.948 s    10 runs
     
    Benchmark 3: mise exec python@3.11 -- python e.py
      Time (mean ± σ):      1.375 s ±  0.011 s    [User: 1.356 s, System: 0.022 s]
      Range (min … max):    1.366 s …  1.403 s    10 runs
     
    Benchmark 4: mise exec python@3.14 -- python e.py
      Time (mean ± σ):      1.302 s ±  0.003 s    [User: 1.284 s, System: 0.022 s]
      Range (min … max):    1.298 s …  1.307 s    10 runs
     
    Summary
      mise exec python@pypy3.11 -- python e.py ran
        8.79 ± 0.11 times faster than mise exec python@3.14 -- python e.py
        9.28 ± 0.13 times faster than mise exec python@3.11 -- python e.py
       13.05 ± 0.16 times faster than mise exec python@3.9 -- python e.py
https://gist.github.com/llimllib/0eda0b96f345932dc0abc2432ab...

Re: Python 3.15’s interpreter for Windows x86-64 should hopefully be 15% faster

#119
post #23

Earlier quoted context omitted.

[flagged]

I don't understand why your mind went immediately to pornography. Kind of creepy tbh.

You must not have ever done any work in communications or PR, it's extremely off limits for a reason.
Post reply on HN