Matt Godbolt was saying recently that using tail-calls for an interpreter suits the branch predictor inside the cpu. Compared to a single big switch / computed jump.
Python 3.15’s interpreter for Windows x86-64 should hopefully be 15% faster
91–100 of 164 posts
Re: Python 3.15’s interpreter for Windows x86-64 should hopefully be 15% faster
#922 typos in first sentence. Is this on purpose to make it obviously not-AI generated?
"apology peice" and "tail caling"
Re: Python 3.15’s interpreter for Windows x86-64 should hopefully be 15% faster
#932 typos in first sentence. Is this on purpose to make it obviously not-AI generated? "apology peice" and "tail caling"
If you want to make your writing appear non-AI generated, the easiest way is to write it yourself. No typos necessary.
I’m sure with enough cajoling you can make the LLM spit out a technical blog post that isn’t discernibly slop - wanton emoji usage, clichés, self-aggrandizement, relentlessly chipper tone, short “punchy” paragraphs, an absence of depth, “it’s not just X—it’s a completely new Y” - but it must be at least a little tricky what with how often people don’t bother.
[ChatGPT, insert a complaint about how people need to ram LLMs into every discussion no matter how irrelevant here.]
Re: Python 3.15’s interpreter for Windows x86-64 should hopefully be 15% faster
#94So…if the Python team finds tail calls useful, when are we going to see them in Python?
Re: Python 3.15’s interpreter for Windows x86-64 should hopefully be 15% faster
#952 typos in first sentence. Is this on purpose to make it obviously not-AI generated? "apology peice" and "tail caling"
Woops, thanks for noticing, fixed!
Re: Python 3.15’s interpreter for Windows x86-64 should hopefully be 15% faster
#96I've never seen this kind of benchmark graph before, and it looks really neat! How was this generated? What tool was used for the benchmarks? (I actually spent most of Sep/Oct working on optimizing the Immer JS immutable update library, and used a benchmarking tool called `mitata`, so I was doing a lot of this same kind of work: https://github.com/immerjs/immer/pull/1183 . Would love to add some new tools to my reper…
Are you referring to the violin plot? https://en.wikipedia.org/wiki/Violin_plot and in Matplotlib as https://matplotlib.org/stable/api/_as_gen/matplotlib.pyplot.... It's in essence a histogram for the distribution, with smoothing, and mirrored on each side. It looks nice, but is not without well-deserved opposition because 1) the use of smoothing can hide the actual distribution, 2) mirroring contains no extra inform…
Histograms aren't necessarily a true depiction of the distribution. Bin count or width has a large impact on what details get shown.
Re: Python 3.15’s interpreter for Windows x86-64 should hopefully be 15% faster
#97Earlier quoted context omitted.
Microsoft was the one hiring Guido out of retirement, and alongside Facebook finally kicking off the CPython JIT efforts. Python is one of the Microsoft blessed languages on their devblogs.
How to stay employed for life: create a programming language which is pretty good, but with some fatal flaws (GIL, typing, slow) and you are set for life.
I don’t know about calling them fatal, but inculcating a culture that believes the flaws are inescapable laws of reality is probably key.
Re: Python 3.15’s interpreter for Windows x86-64 should hopefully be 15% faster
#98Earlier quoted context omitted.
Microsoft was the one hiring Guido out of retirement, and alongside Facebook finally kicking off the CPython JIT efforts. Python is one of the Microsoft blessed languages on their devblogs.
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% faster than CPython 3.10 for pyperformance x86-64 Ubuntu https://github.com/faster-cpython/benchmarking-public
These speedups have been verified by external projects. For example, a Python MLIR compiler that I follow has found a geometric mean 36% speedup moving from CPython 3.10 to 3.11 (page 49 of https://github.com/EdmundGoodman/masters-project-report)
Another academic benchmark here observed an around 1.8x speedup on their benchmark suite for 3.13 vs 3.10 https://youtu.be/03DswsNUBdQ?t=145
CPython 3.11 sped up enough that PyPy in comparison looks slightly slower. I don't know if anyone still remembers this: but back in the CPython 3.9 days, PyPy had over 4x speedup over CPython on the PyPy benchmark suite, now it's 2.8 on their website https://speed.pypy.org/ for 3.11.
Yes CPython is still slow, but it's getting faster :).
Disclaimer: I'm just a volunteer, not an employee of Microsoft, so I don't have a perf report to answer to. This is just my biased opinion.
Re: Python 3.15’s interpreter for Windows x86-64 should hopefully be 15% faster
#99Earlier quoted context omitted.
> not even the biggest timewaster of python, which is the packaging "system". For frequent, short-running scripts: start-up time! Every import has to scan a billion different directories for where the module might live, even for standard modules included with the interpreter.
In the near future we will use lazy imports :) https://peps.python.org/pep-0810/
This can't come soon enough. Python is great for CLIs until you build something complex and a simple --help takes seconds. It's not something easily worked around without making your code very ugly.
Re: Python 3.15’s interpreter for Windows x86-64 should hopefully be 15% faster
#100[flagged]