| ▲ | adrian17 6 hours ago |
| Unfortunate. I've been following the work on it occasionally. On one hand, it seemed like JIT work was really progressing in high gear until SC requested a new PEP. Also unfortunate, as it seemed like part of the hope for the JIT was that it'd counter the performance penalty from free threading. On the other, it did feel (to me) like with all the fancy (and definitely cool) optimizations it got (automatic refcount operation removal, new type-based specializations, inplace math operations), the macrobenchmark benefits weren't _that_ exciting for a JIT. It definitely has potential for more, maybe with even fancier optimizations like unboxing ints, but the complexity just keeps going up. > It said that the PEP was "overly optimistic" about user-visible differences with the JIT enabled. The JIT is technically generated from the same source as the interpreter loop itself, so originally the differences were extremely unlikely, but I imagine the risk just kept going up as new JIT-only paths and optimizations were introduced. And politically, I feel like SC’s reasoning was just “this side project has landed in main branch almost by accident and has been stewing without oversight ever since, with no stabilization in sight”; and the latest PEP was probably still too vague, with a lot of “here’s more things we can add to the stew” - so I can understand if SC wasn’t satisfied. |
|
| ▲ | cogman10 4 hours ago | parent | next [-] |
| I think this is a major issue with requiring a PEP for what's a performance optimization. JITs are big nasty things that by their nature have to do a lot of things. You are basically saying "Give us a PEP for a new python interpreter and compiler". What they do is fuzzy by their nature because optimizations are very rarely universally beneficial. It's a game of measuring, looking for regressions, and tackling the biggest problem next for whatever sample applications you have available. You always run into the risk of overfitting on top of all that (You may have made django faster, but you've made flask slower). This is the sort of thing that, IMO, should not go through the PEP process. It's an implementation detail for the runtime. Imagine, for example, if the JVM needed a bunch of JEPs for JIT improvements. They'd never get done. Or if any javascript engine needed ECMA acceptance before they could do a new JIT optimization. |
| |
| ▲ | stickfigure 4 hours ago | parent | next [-] | | > Imagine, for example, if the JVM needed a bunch of JEPs for JIT improvements. They do: https://openjdk.org/jeps/197 https://openjdk.org/jeps/515 Not every optimization requires a JEP, but certainly something as big as "add or remove a JIT" would 100% require a JEP. | |
| ▲ | adrian17 4 hours ago | parent | prev [-] | | > Imagine, for example, if the JVM needed a bunch of JEPs for JIT improvements. FWIW, I definitely can find a bunch of both PEPs and JEPs for internal optimizations, random examples: https://peps.python.org/pep-0509/ https://openjdk.org/jeps/147 | | |
| ▲ | cogman10 4 hours ago | parent [-] | | You can find those JEPs, but frankly they are there for 1 of 2 reasons. 1. An outsider to the regular OpenJDK dev team proposing an optimization. 2. Advertising for a cool new performance tweak with potentially large impact. You'll also notice that the JEP descriptions are very different from PEP descriptions. Probably the largest JEP for the JVM, Valhalla https://openjdk.org/jeps/401 Does not have the same level of requirements being asked of the Python JIT. Further, it's well understood that this JEP will "live on main" for quite some time in preview before it's accepted and merged. What the JEP does, instead, is simply describe the feature and potential risks. The vast majority of JVM optimizations do not get a JEP. | | |
| ▲ | adrian17 4 hours ago | parent [-] | | Fair, I don’t argue with that, I’m not knowledgeable about Java’s processes. Just one thing: > The vast majority of JVM optimizations do not get a JEP. In Python too. Still, the JIT really is just a really big thing. I don’t know if there could be a better way to do it, as either 1. You develop it off-branch and… make an enormous PR when you’re done, with risks of getting rejected anyway? Or 2, you allow more experiments on main like Rust, but then you end up with hundreds of minor half-maintained nightly-only features, possibly conflicting with each other, and eventually go through bureaucracy to remove them anyway. | | |
| ▲ | cogman10 2 hours ago | parent [-] | | So, I'd grant that it'd probably be a JEP for java (the initial JIT) but not that every change to the JIT would result in a new JEP. Java's JIT, hotspot, was integrated right before they started the JEP process. The JEP for the JIT would likely be pretty boring like "It's a JIT, it does this, in some applications we see this sort of speed up". Much like the AOT JEP https://openjdk.org/jeps/514 The Java governance allows for a lot more open ended projects with follow ups. Not that it's reckless, Valhalla is proof of that, but rather that once something is good enough they are pretty open to just shipping it as a preview feature and refining until it is worthy of being stable. That's why, for example, we saw ZGC get merged, and then JDK after JDK seeing continuing development and improvement on ZGC (Or G1 for that matter). These GCs were fairly rough on their first release and now they are pretty much best in class. I see a Python JIT as the same thing. Delivering the infrastructure for a JIT would need a PIP, but I wouldn't put in things like "acceptance criteria" beyond "doesn't break older code". I would expect such a project to get continual updates without PEPs. | | |
| ▲ | adrian17 36 minutes ago | parent [-] | | > I would expect such a project to get continual updates without PEPs. Just for completeness: the original JIT PR was merged quite enthusiastically
and only after the fact it was pointed out that it should have went through a PEP process [1]. The following PEP 744 was of the “informational” type, and the just-withdrawn PEP 836 was the first “standards track” PEP, which means that (in my understanding) it’s technically the first actual PEP that the SC would formally comment on. So in a way it’s not “can we update the JIT” PEP, but the first real “does SC want this JIT as proposed” PEP. That said, I do agree with most of what you said, especially the acceptance criteria part. The issue I have and find it hard to resolve is that since the code was already on main, the feature was already in “sunk cost” mode. It’s hard when the code is already on main and another 3 optimization PRs are always there behind the corner, but it needs to be possible for SC to say “we decided it’s not actually worth all this complexity for <some small number>% speed improvement” (I’m not commenting whether in this particular case it’d have been a right call), and the PEP (if not withdrawn) was the way to exercise that control. [1] https://github.com/python/cpython/pull/113465#issuecomment-1... |
|
|
|
|
|
|
| ▲ | 4 hours ago | parent | prev | next [-] |
| [deleted] |
|
| ▲ | ActorNightly 3 hours ago | parent | prev [-] |
| I mean, I have had great success with prototyping stuff in python, then letting an llm translate it to C. My 3090 with Gemma4:31b does this very well with a few guidelines. Dunno how much investment is needed into language optimization anymore. |
| |
| ▲ | 14113 2 hours ago | parent | next [-] | | That works well for greenfield code, but if working on compiler optimisations has taught me anything, it's that there is a lot of legacy code out there in the world that would benefit from re-compilation with optimisations - but would be very difficult to re-write for speed (regardless of whether the work is done by a human, AI, or other machine tool). JIT compilation fits very nicely in this niche, as it means that existing Python projects can get (theoretically) better performance without re-writing. | |
| ▲ | mring33621 2 hours ago | parent | prev [-] | | Agree with the general workflow: prototype with an easy-to-read language then port to lower-level, faster language |
|
