4 ms·
On performance: 3.13 removed the GIL and added experimental first-party JIT (like PyPy). In two years I bet we’ll be seeing v8 level performance out of CPython
by Jaxkr 11mo ago
On performance: 3.13 removed the GIL and added experimental first-party JIT (like PyPy).
In two years I bet we’ll be seeing v8 level performance out of CPython.
- motoboi 11mo agoI bet we’ll be seeing python compiled to JVM of getting JVM levels of performance. Much better than v8
- necovek 11mo agoThere have for a long time been IronPython (CLR) and and Jython (JVM). But, they don't have the full compatibility with CPython, so nobody really picks them up.
- CamouflagedKiwi 11mo agoJython seems to be effectively dead though - it only has 2.7 compatibility.
- necovek 11mo agoYou are right: GraalPy (https://www.graalvm.org/python/ https://www.graalvm.org/python/) is where it's at these days.
- animuchan 11mo agoJVM Python exists for the longest time now, where "exists" is purely technical. It's very cursed and bad, keeping in line with the rest of Java-adjacent stack.
- homebrewer 11mo agoYet this "Java-adjacent stack" wipes the floor with Python and its ilk w.r.t performance and is what's actually running the world outside of some silicon valley ephemeral unicorns.
- t43562 11mo agoTry https://www.graalvm.org/python/ https://www.graalvm.org/python/
- pansa2 11mo agoThe “Faster CPython” team were let go from Microsoft because they could only produce a 1.5x speedup in four years instead of the planned 5x. It’s wildly optimistic to now expect a 10x speedup in two years, with fewer resources.
- y1n0 11mo agoDepends if they are the right resources.
- fmbb 11mo agoDepends if it’s possible.
- spooky_deep 11mo agoPython is slow due to design decisions in the language. For example operator dispatch is slow without some kind of static analysis. But this is hindered by how dynamic the language is.
- ogogmad 11mo agoIt's hard to make Python run fast when it pervasively uses duck typing. It makes types only resolvable at runtime. JIT is the only thing that can work here at the moment, but I think that needs to make very similar assumptions to a branch predictor, plus it needs to identify lexical regions (is that what they're called?). People here have criticised PyPy, but I've forgotten why.
- danielscrubs 11mo agoWow, know you make me curious about the business processes at Microsoft. Did they see that they would earn more money if the interpreter had a 5x speedup, that they wouldn’t see with 1.5x? Or was it trust broken?
- eptcyka 11mo ago
- heavyset_go 11mo agoI'd be surprised if we saw anything more than the 4x speedup from compiling Python with something like Nuitka/mypyc/etc can bring. I also believe the JIT in v8 and Python are different, the latter relying on copy-and-patch while v8 uses a bunch of different techniques together.
- zahlman 11mo agoObviously dumb microbenchmark, but here's ~17x on my machine: $ time python -c 'sum(range(1_000_000_000))' real 0m19.997s user 0m19.992s sys 0m0.005s $ time pypy -c 'sum(range(1_000_000_000))' real 0m1.146s user 0m1.126s sys 0m0.020s
- heavyset_go 11mo agoI think some relatively simple math JITs and compiles nicely like that, but when you start using other parts of the language heavily like you would in a real project, it averages out to about ~4x due to the object, VM and locking model, I believe. It's been a while since I've looked into this.
- rslashuser 11mo agoI would surprised to see performance as good as V8, although that would be great. As I recall the v8 team performed exceptionally well in a corporate environment that badly wanted js performance to improve, and maybe inherited some Hotspot people at the right time. I'd be quite delighted to see, say, 2x Python performance vs. 3.12. The JIT work has potential, but thus far little has come of it, but in fairness it's still the early days for the JIT. The funding is tiny compared to V8. I'm surprised someone at Google, OpenAI et al isn't sending a little more money that way. Talk about shared infrastructure!
- ShroudedNight 11mo agoHas something changed that allows a more relaxed refcounting / less eager "gc"? Py_DECREF was what murdered any hope of performance back when we hooked up 3.3 to OMR... Well that and the complete opacity of everything implemented in C
- t43562 11mo agopypy is probably faster. Lets put effort into that. BUT the dynamic features that make python lovely are always going to limit its performance. If you're using python because you have to then you might not like all that and might see it as something to toss out. This makes me sad.
- CamouflagedKiwi 11mo agoIt didn't "remove the GIL". It added an experimental free-threading mode which removes it, but is still considered experimental and not widely used in production yet.