Python 3.15's JIT is now back on track
fidget-spinner.github.io
Python 3.15's JIT is now back on track
1–10 of 330 posts
Re: Python 3.15's JIT is now back on track
#2> We don’t have proper free-threading support yet, but we’re aiming for that in 3.15/3.16. The JIT is now back on track.
I recently read an interview about implementing free-threading and getting modifications through the ecosystem to really enable it: https://alexalejandre.com/programming/interview-with-ngoldba...
The guy said he hopes the free-threaded build'll be the only one in "3.16 or 3.17", I wonder if that should apply to the JIT too or how the JIT and interpreter interact.
Re: Python 3.15's JIT is now back on track
#3Doesn't PyPy already have a jit compiler? Why aren't we using that?
Re: Python 3.15's JIT is now back on track
#4Doesn't PyPy already have a jit compiler? Why aren't we using that?
As far as I know, PyPy doesn't support all CPython extensions, so pure Python code will probably (very likely) run fine but for other things most bets are off. I believe PyPy also only supports up to 3.11?
Re: Python 3.15's JIT is now back on track
#5Doesn't PyPy already have a jit compiler? Why aren't we using that?
Because PyPy seems to be defunct. It hasn't updated for quite a while.
See https://github.com/numpy/numpy/issues/30416 for example. It's not being updated for compatibility with new versions of Python.
Re: Python 3.15's JIT is now back on track
#6[flagged]
Re: Python 3.15's JIT is now back on track
#7I'm been occasionally glancing at PR/issue tracker to keep up to date with things happening with the JIT, but I've never seen where the high level discussions were happening; the issues and PRs always jumped right to the gritty details. Is there anywhere a high-level introduction/example of how trace projection vs recording work and differ? Googling for the terms often returns CPython issue tracker as the first result, and repo's jit.md is relatively barebones and rarely updated :(
Similarly, I don't entirely understand refcount elimination; I've seen the codegen difference, but since the codegen happens at build time, does this mean each opcode is possibly split into two (or more?) stencils, with and without removed increfs/decrefs? With so many opcodes and their specialized variants, how many stencils are there now?
Re: Python 3.15's JIT is now back on track
#8[flagged]
I am trying to push back. I don't care if other people think the tools make them faster, I did not sign up to be a guinea pig for my employer or their AI-corp partner.
Re: Python 3.15's JIT is now back on track
#9Doesn't PyPy already have a jit compiler? Why aren't we using that?
Why shouldn't the reference implementation get JIT? Just because some other implementations already have it is no reason not to. That'd be like skipping list comprehensions because they already exist in CPython.