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 language would get so much positive feedback for so little.

▲ kenjin4096 11 hours ago | parent | next [-]

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

▲ tom_ 9 hours ago | parent [-]

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

	▲	llimllib 9 hours ago \| parent \| next [-]
		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...
	▲	eru 6 hours ago \| parent \| prev [-]
		> [...] and I've just assumed the performance will still be as limited as it always has been...!) Historically CPython performance has been so bad, that massive speedups were quite possible, once someone seriously got into it.

▲ pjmlp 14 hours ago | parent | prev [-]

I know what happened last year, my point was the prior history that lead to that effort.

https://thenewstack.io/guido-van-rossums-ambitious-plans-for...

Agree with the sentiment, Python is the only dynamic language where it seems a graveyard from efforts.

And nope it isn't the dynamism per se, Smalltalk, Self, Common Lisp are just as dynamic, with lots of possibilities to reboot the world and mess up JIT efforts, as any change impacts the whole image.

Naturally those don't have internals exposed to C where anything goes, and the culture C libraries are seen as the language libraries.

▲

boulos 13 hours ago | parent [-]

Ehh, PHP fits that bill and is clearly optimizable. All sorts of things worked well for PHP, including the original HipHop, HHVM, my own work, and the mainline PHP runtime.

Python has some semantics and behaviors that are particularly hostile to optimization, but as the Faster Python and related efforts have suggested, the main challenge is full compatibility including extensions plus the historical desire for a simple implementation within CPython.

There are limits to retrofitting truly high performance to any of these languages. You want enough static, optional, or gradual typing to make it fast enough in the common case. That's why you also saw the V8 folks give up and make Dart, the Facebook ones made Hack, etc. It's telling that none of those gained truly broad adoption though. Performance isn't all that matters, especially once you have an established codebase and ecosystem.

▲

gsnedders 13 hours ago | parent | next [-]

> Performance isn't all that matters, especially once you have an established codebase and ecosystem.

And this is no small part of why Java and JS have frequently been pushing VM performance forward — there’s enough code people very much care about continuing to work on performance. (Though the two care about different things mostly: Java cares much more about long-term performance, and JS cares much more about short-term performance.)

It doesn’t hurt they’re both languages which are relatively static compared with e.g. Python, either.

▲

titzer 6 hours ago | parent | prev [-]

> you also saw the V8 folks give up and make Dart

V8 still got substantially faster after the first team left to do Dart. A lot of runtime optimizations (think object model optimizations), several new compilers, and a lot of GC work.

It's a huge investment to make a dynamic language go as fast as JS these days.

	▲	eru 6 hours ago \| parent [-]
		> It's a huge investment to make a dynamic language go as fast as JS these days. Yes, and on the other hand, other language implementations like CPython can learn from everything people figured out for JS.