>The experimental JIT was reported to finally breaking even and surpassing the default interpreter just a couple of months ago[1].
replyThank You. As someone who don't follow python closely I thought their JIT would be similar to what Ruby has.
Not that Ruby YJIT or ZJIT is anywhere close to what JVM provides, but in this case it seems to be quite far ahead of Python.
Which is surprising given how many major companies are using Python. May be because those using Python are not using it as critical part of work unlike Shopify and Stripe which is their core language?
Python software is to a large extent either doing things in not-python (c, c++, rust, etc.) or doing things that are not cpu bound (io bound, async, etc.). If you're cpu bound then you can either take a 2x jit improvement or take a 10x non-python improvement. There's few companies of a scale where the non-hot path cost of 2x cpu is so massive as to be worth caring about.
replySure but best case 15% faster clearly isn't worth the complexity of a JIT. It really needs to be at least twice as fast. Pypy pretty much achieves that on average.
reply15% faster on top of a base interpreter that itself got 40%-50% faster on the same timeframe.
replyKind of a shit move to suddenly pull the rug once they've finally gotten it working. Should have been kept out of main from the start.
replyThe post clearly says the intention is to get a formal spec for formal integration.
replyTo leave their experimental phase they have to define some goals to meet and that requires making some architectural choices that still aren't decided.
I suspect the recent "we updated the GC without a PEP and it went live and caused massive issues and we need an emergency point release revert" pushed for a greater degree of process overall.
reply