Python 3.14 is here. How fast is it?
- Tangential, but I practically owe my life to this guy. He wrote the flask mega tutorial in what I followed religiously to launch my first website. Then right before launch, in the most critical part of my entire application; piping a fragged file in flask. He answered my stackoverflow question, I put his fix live, and the site went viral. Here's the link for posterity's sake https://stackoverflow.com/a/34391304/4180276
- Please don’t make benchmarks with timing inside the loop creating a sum. Just time the loop and divide by the number. Stuff happens getting the time and the jitter can mess with results.
- Every time I hear news about Python language itself, it sadden me that, in 2025, PyPy is still a separate distinct track from mainline Python.
That said, I wonder if GIL-less Python will one day enable GIL-less C FFI? That would be a big win that Python needs.
- I hope it doesn't get stuck at 3.14, like TeX.
https://www.reddit.com/r/RedditDayOf/comments/7we430/donald_...
- More than 300 comments here and still no convincing answer. Why the community wastes time on trying to make CPython faster when there is pypy which is already much faster? I understand pypy lacks libraries and feature parity with up to date CPython. But… can’t everyone refocus the efforts and just move to pypy to add all the missing bits and then just continue with pypy as the “official python”? Are there any serious technical reasons not to do it?
by anaccount342
4 subcomments
- I don't know how realistic only using a benchmark that only uses tight loops and integer operations. Something with hashmaps and strings more realistically represents everyday cpu code in python; most python users offload numeric code to external calls.
- For me the "criminal" thing is that Pypy exists on a shoestring and yet delivers the performance and multithreading that others gradually try to add to cpython.
It's problem is, IMO, compatibility. Long ago I wanted to run it on yocto but something or other didn't work. I think this problem is gradually disappearing but it could be solved far more rapidly with a bit of money and effort probably.
by veber-alex
0 subcomment
- The most interesting part for me is that PyPy is faster than free threaded CPython even on multi threaded code.
- Really pleasing to see how smooth the non-GIL transition was. If you think about 2->3 python this was positively glorious.
And that it gets into spitting range of standard so fast is really promising too. That hopefully means the part not compatible with it get flushed out soon-ish
- Do any of these tests measure the new experimental tail call interpreter (https://docs.python.org/3.14/using/configure.html#cmdoption-...)?
I couldn't find any note of it, so I would assume not.
It would be interesting to see how the tail call interpreter compares to the other variants.
- Python installation size over time:
170M python-3.6.15
183M python-3.7.17
197M python-3.8.20
206M python-3.9.24
218M python-3.10.19
331M python-3.11.14
362M python-3.12.12
377M python-3.13.8
406M python-3.14.0
by sandGorgon
0 subcomment
- pypy has frequently struggled with funding. Here's a link if you want to donate this christmas https://opencollective.com/pypy
by lenerdenator
0 subcomment
- That >2x performance increase over 3.9 in the first test is pretty impressive. A narrow use case for sure, but assuming you can leave your code completely alone and just have it run on a different interpreter via a few CLI commands, that's a nice bump.
- For quick and dirty Python benchmark, try
https://github.com/DarkStar1982/fast_langton_ant/
Run as "python3 server.py -s 10000000 -n"
by modeless
22 subcomments
- What are the reasons why nobody uses pypy?
by DeathArrow
2 subcomments
- I feel like Python should be much faster already. With all the big companies using Python and it's huge popularity I would have expected that a lot of money, work and research would be put into making Python faster and better.
by Phelinofist
4 subcomments
- Pithon, haha
by notepad0x90
2 subcomments
- 3.1415.. Pithon??
by ModernMech
4 subcomments
- I'm thankful they included a compiled language for comparison, because most of the time when I see Python benchmarks, they measure against other versions of Python. But "fast python" is an oxymoron and 3.14 doesn't seem to really change that, which I feel most people expected given the language hasn't fundamentally changed.
This isn't a bad thing; I don't think Python has to be or should be the fastest language in the world. But it's interesting to me seeing Python getting adopted for a purpose it wasn't suited for (high performance AI computing). Given how slow it is, people seem to think there's a lot of room for performance improvements. Take this line for instance:
> The free-threading interpreter disables the global interpreter lock (GIL), a change that promises to unlock great speed gains in multi-threaded applications.
No, not really. I mean, yeah you might get some speed gains, but the chart shows us if you want "great" speed gains you have two options: 1) JIT compile which gets you an order of magnitude faster or 2) switch to a static compiled language which gets you two orders of magnitude faster.
But there doesn't seem to be a world where they can tinker with the GIL or optimize python such that you'll approach JIT or compiled perf. If perf is a top priority, Python is not the language for you. And this is important because if they change Python to be a language that's faster to execute, they'll probably have to shift it away from what people like about it -- that it's a dynamic, interpreted language good for prototyping and gluing systems together.
- seems loved languages such as python & ruby (ZJIT | TruffuleRuby) have been getting a lot performance improvements lately. of course JS with v8 kickstarted this - followed by PHP.
so for majority of us folks use what you love - the performance will come.
by moralestapia
4 subcomments
- Very interesting post, thanks for putting it together.
Rust is indeed quite fast, I thought NodeJS was much better tbh., although it's not bad. I'd be interested to learn what's holding it back because I've seen many implementations where V8 can get C++-like performance (I mean it's C++ after all). Perhaps there's a lot of overhead in creating/destroying temporary objects.
by aussieguy1234
0 subcomment
- I started using Python again recently after a 15 year break. The reason was I started working with LangChain, specifically LangGraph agents. The JavaScript/TypeScript versions are months behind. In the AI world with the progress thats been made recently, months might as well be years.
- Is fold comment a option based on karma or something? I loved the most voted post here on how Miguel helped the guy but, it is unrelated and for the first time I guess I realized there is no fold so I can go to people actually talking about the article...
- How did they not take the opportunity with this version to rename it pi-thon?
by nullorempty
0 subcomment
- '3.14159265359...' - there is a lot of room to grow - keep it at pi
- I’m very glad python is getting faster. But the correct answer to “Is Python Really That Slow?” is unambiguously YES. Unless you’re using some ML library like torch or numpy which spends all its time in optimized C code, python is still EXTREMELY slow. We are going to need a lot of these 10% improvements for python to be comparable to Go, Java, or Node, each of which are about 30x faster on typical computer tasks.
- No comparison to Python 2.7.18.
- For all those making πthon jokes: https://github.com/python/cpython/pull/125035
- Missed opportunity for "Pi thon 3.14 is here. How fast is it?"
by thaumasiotes
0 subcomment
- Aha, the perfect time for Python to adopt the TeX version numbering system.
by curiousityargh
1 subcomments
- Kinda curious. Have you figured out why the code runs faster on a Mac?
- I like the Rust being there. It is a reality check to keep the numbers in perspective. (C, C++ or something like that would work too)
by librasteve
2 subcomments
- Very nice post - it's good to see benchmarks done for humans.
For fun, I tried this in Raku:
(0, 1, *+* ... *)[40] #0.10s user 0.03s system 63% cpu 0.214 total
lolSeriously, Python is doing great stuff to squeeze out performance from a scripting language. Realistically, Raku has fewer native libraries (although there is Inline::Python) and the compiler still has a lot of work to get the same degree of optimisation (although one day it could compare).
EDIT: for those who have commented, yes you are correct … this is a “cheat” and does not seek to state that Raku is faster than Python - as I said Raku still has a lot of work to do to catch up.
- It remains solidly among the slowest languages you could choose. Consider your use case and the trade-offs wisely.
- Here's hoping they make 16 patch versions
- Why isn’t Pypy the default recommended runtime?
The performance increase seems jaw dropping.
- I have 128 cores on my machine, Python still do not use them all.
by ctkqiang96
0 subcomment
- So finally we can call it π-thon？
- π-thon is finally here
by guardian5x
0 subcomment
- Gees, Rust is fast!
- For a while the language will be named PIthon
by alfalfasprout
1 subcomments
- > And this is a bit disappointing. At least for this test, the JIT interpreter did not produce any significant performance gains, so much that I had to double and triple check that I used a correctly built interpreter with this feature enabled. I do not know much about the internals of the new JIT compiler, but I'm wondering if it cannot deal with this heavily recursive function.
FWIW one thing that is worth calling out here is that the initial goal for JIT right now in Python is getting it relatively stable, functional, and more or less getting the initial implementation out there. It's not surprising at all that it's not faster.
I say this because I think the teams working on free-threaded and JIT python maybe could have done a better job publicly setting expectations.
by 1vuio0pswjnm7
3 subcomments
- Only tested against NodeJS and Rust
What about Lua and LuaJIT
- object oriented developer language, whereas the API is the mass-production of backend apps
by zeroonetwothree
0 subcomment
- πthon
- https://archive.ph/W0IL2
- Pi-thon
by cat-whisperer
0 subcomment
- Yeah honestly I don't really care about these benchmarks. Python isn't built for raw performance and that's totally fine! It's the number one choice for prototyping and can do so much, that's what actually matters. I think it's cool they're working on speed improvements though, means my prototype-to-production cycle gets a bit smoother lol.
- So, Π-thon?
- Pi-thon?
by BurningFrog
0 subcomment
- Let this version be known as PiPy!
- Can we call it Py Pi ?
- python pi!
- pi-thon
- I know this is not a highquality comment, but this must be the ideal language to run on a raspberry Pi. I'll see myself out; I also do Bar Mitzwahs.
- Pi-thon?
- more like "pi"thon
by semiinfinitely
0 subcomment
- honestly if the performance of the python interpreter has a big impact on your application's performance and that's something you care about - you're already doing things very wrong
by OhNoNotAgain_99
0 subcomment
- [dead]
by username223
1 subcomments
- tl;dr: Two orders of magnitude slower than Rust, so 2-3 orders slower than native. Python on a 2 GHz processor runs as fast as C on a 2-20 MHz processor.
- tl;dr... It's still not fast
- Pi-thon
- Py = 3.14 :')
- It's slow.
Get back to work.
by LigmaBaulls
3 subcomments
- I would tell you a joke about python but it would take you a long time to get it.
Hacker News