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

Them being let go "because they didn't meet 5x" is hearsay. The only source for that is in social-media commentary and opinion pieces. Microsoft described the layoffs as "organizational adjustments".

That sounds awfully like a scene by scene replay of Google's Unladen Swallow experience.

https://peps.python.org/pep-3146/#rationale-implementation

At least Microsoft hired a bunch of experienced Python core developers for their effort. IIRC Unladen Swallow was just a couple of interns.

Wow, 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?

Instead of generating more revenue, it would drive down costs. You will need less computers to do the same amount of work if the work can be done faster.

Lower costs could open new markets, as it would allow you to charge less and still make a profit.

Depends if they are the right resources.

Depends if it’s possible.

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

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

Have you checked out what PyPy is already capable of?

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

Obviously 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

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

I 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!

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

I bet we’ll be seeing python compiled to JVM of getting JVM levels of performance. Much better than v8

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

Jython seems to be effectively dead though - it only has 2.7 compatibility.

You are right: GraalPy (https://www.graalvm.org/python/) is where it's at these days.

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

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

Try https://www.graalvm.org/python/

Has 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

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