[Qem]

> For that reason, the Steering Council is formally requesting a Standards Track PEP be authored that the community can discuss and the Steering Council can formally accept (or reject), making the case for the JIT as a supported, non-experimental part of CPython: its guarantees, its maintenance commitments, and its impact on redistributors.

I didn't notice the current PEP was a provisional one. Hope the new one gets approved. The experimental JIT was reported to finally breaking even and surpassing the default interpreter just a couple of months ago[1].

[1] https://fidget-spinner.github.io/posts/jit-on-track.html

[ksec]

>The experimental JIT was reported to finally breaking even and surpassing the default interpreter just a couple of months ago[1].

Thank 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?

[bob001]

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.

[thatguysaguy]

The python overhead of launching big ML jobs is nontrivial, so I think speeding that up would be meaningful. (I mean the initial tracing and other setup, not things once the GPUs are actually doing the work).

[bob001]

That seems more like the tracing overhead than the python overhead. The original jit proposal would I believe not help at all with that since ML workloads basically do their own jit. The post being discussed however pushes for a general framework and good tracing support so might help ML workloads.

[jbvlkt]

Also you can use projects like numba https://numba.pydata.org/

[IshKebab]

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

[Qem]

15% faster on top of a base interpreter that itself got 40%-50% faster on the same timeframe.

[IshKebab]

Right... but it's still only 15% faster than a simpler alternative. In a language that is 50x slower than the alternatives. Clearly not worth it.

Of course the counterargument is that they'll improve it and maybe in future it will be 100% faster... But that seems pretty dubious given the progress so far.

[germandiago]

When I choose Python for something, it is clearly for its speed.

It is nice to have the speed, always. But in Python, it would be a mistake to do it at the expense of flexibility. Same for typing: it is great to have it. I use it. But Python should be dynamic and the rest and extension that does not compromise everything else.

If a JIT can make Python 2 or 3x faster, or even 10x for some workloads, that is nice. But the language itself should support same idioms, reflection, dynamic typing, etc at the same level.

[germandiago]

oh, I meant it is clearly NOT for its speed.

[mike_hock]

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

[oliwarner]

The post clearly says the intention is to get a formal spec for formal integration.

To leave their experimental phase they have to define some goals to meet and that requires making some architectural choices that still aren't decided.

[bob001]

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.