Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Python 3.15's JIT is now back on track

fidget-spinner.github.io

Post reply on HN
Print view View original

71–80 of 330 posts

Re: Python 3.15's JIT is now back on track

#71

Post by vanderZwan »

> However, I misunderstood and came up with an even more extreme version: instead of tracing versions of normal instructions, I had only one instruction responsible for tracing, and all instructions in the second table point to that. Yes I know this part is confusing, I’ll hopefully try to explain better one day. This turned out to be a really really good choice. I found that the initial dual table approach was so much slower due to a doubling of the size of the interpreter, causing huge compiled code bloat, and naturally a slowdown.

> By using only a single instruction and two tables, we only increase the interpreter by a size of 1 instruction, and also keep the base interpreter ultra fast. I affectionally call this mechanism dual dispatch.

I really do hope they'll write that better explanation one day because this sounds pretty intriguing all on its own.

Re: Python 3.15's JIT is now back on track

#72

Post by punnerud »

__mharrison__ wrote: post #63
froobius wrote: post #54

Earlier quoted context omitted.

On the other hand, taking backwards compatibility so seriously is a big part of the massive success of Python

I would argue that the libraries, and specifically NumPy, are the reason Python is still in the picture today. It will be interesting to see, moving forward, what languages survive. A 15% perf increase seems nice, until you realize that you get a 10x increase porting to Rust (and the AI does it for you). Maybe library use/popularity is somewhat related to backwards compatibility. Disclaimer: I teach Python for a livi…

And PyTorch, and Pandas, and, and…

Re: Python 3.15's JIT is now back on track

#73

Post by veber-alex »

pansa2 wrote: post #65
zarzavat wrote: post #61

Earlier quoted context omitted.

I continue to believe that free-threading hurts performance more than it helps and Python should abandon it. Having to have thread safe code all over the place just for the 1% of users who need to have multi-threading in Python and can't use subinterpreters for some reason is nuts.

Maybe they could have two versions of the interpreter, one that’s thread-safe and one that’s optimised for single-threading? Microsoft used to do this for their C runtime library.

That's exactly what we have now and it looks like the python devs want a single unified build at some point

Re: Python 3.15's JIT is now back on track

#74

Post by scorpioxy »

owaislone wrote: post #68

Oh man, Python 2 > 3 was such a massive shift. Took almost half a decade if not more and yet it mainly changing superficial syntax stuff. They should have allowed ABIs to break and get these internal things done. Probably came up with a new, tighter API for integrating with other lower level languages so going forward Python internals can be changed more freely without breaking everything.

The text encoding stuff wasn't a small change considering what it could break, at least. And remember we're sometimes talking about software that would cost a lot of money to migrate or upgrade. I still maintain some 2.x python code-bases that will be very expensive to migrate and the customer is not willing to invest that money.

Although your general sentiment is something I agree with(if it's going to be painful do it and get it over with), I don't believe anybody knew or could've guessed what the reaction of the ecosystem would be.

Your last point about being able to change internals more freely is also great in theory but very difficult(if not impossible) to achieve in practice.

I don't know. Having maintained some small projects that were free and open source, I saw the hostility and entitlement that can come from that position. And those projects were a spec of dust next to something like Python. So I think the core team is doing the best they can. It was always going to be damned if you do, damned if you don't.

Re: Python 3.15's JIT is now back on track

#75

Post by B1FF_PSUVM »

__mharrison__ wrote: post #63
froobius wrote: post #54

Earlier quoted context omitted.

On the other hand, taking backwards compatibility so seriously is a big part of the massive success of Python

I would argue that the libraries, and specifically NumPy, are the reason Python is still in the picture today. It will be interesting to see, moving forward, what languages survive. A 15% perf increase seems nice, until you realize that you get a 10x increase porting to Rust (and the AI does it for you). Maybe library use/popularity is somewhat related to backwards compatibility. Disclaimer: I teach Python for a livi…

> you get a 10x increase porting to Rust (and the AI does it for you)

So, you keep reading/writing Python and push a button to get binary executables through whatever hoops are best today ?

(I haven't seen the "fits your brain" tagline in the recent past ...)

Re: Python 3.15's JIT is now back on track

#76

Post by __mharrison__ »

punnerud wrote: post #72
__mharrison__ wrote: post #63

Earlier quoted context omitted.

I would argue that the libraries, and specifically NumPy, are the reason Python is still in the picture today. It will be interesting to see, moving forward, what languages survive. A 15% perf increase seems nice, until you realize that you get a 10x increase porting to Rust (and the AI does it for you). Maybe library use/popularity is somewhat related to backwards compatibility. Disclaimer: I teach Python for a livi…

And PyTorch, and Pandas, and, and…

Built and or inspired by NumPy...

Re: Python 3.15's JIT is now back on track

#77

Post by pansa2 »

gjvc wrote: post #70
owaislone wrote: post #68

Oh man, Python 2 > 3 was such a massive shift. Took almost half a decade if not more and yet it mainly changing superficial syntax stuff. They should have allowed ABIs to break and get these internal things done. Probably came up with a new, tighter API for integrating with other lower level languages so going forward Python internals can be changed more freely without breaking everything.

yes. it was not a massive shift. it was barely worth the effort.

The Python devs didn’t want to make huge changes because they were worried Python 3 would end up taking forever like Perl 6. Instead they went to the other extreme and broke everyone’s code for trivial reasons and minimal benefit, which meant no-one wanted to upgrade.

Even the main driver for Python 3, the bytes-Unicode split, has unfortunately turned out to be sub-optimal. Python essentially bet on UTF-32 (with space-saving optimisations), while everyone else has chosen UTF-8.

Re: Python 3.15's JIT is now back on track

#78

Post by thunky »

I always wanted this for Python but now that machines write code instead of humans I feel like languages like Python will not be needed as much anymore. They're made for humans, not machines. If a machine is going to do the dirty work I want it to produce something lean, fast, and strictly verified.

Re: Python 3.15's JIT is now back on track

#79

Post by ghm2199 »

Thanks for all the amazing work! I have Noob question. Wouldn't this get the funding back? Or would that not be preferable way to continue(as opposed to just volunteer driven)?

Like this is a big deal to get a project to a state where volunteers are spun up and actively breaking tasks and getting work done, no? It's a python JIT something I know next to nothing about — as do most application developers — which tells one how difficult this must have been.

Re: Python 3.15's JIT is now back on track

#80

Post by rslashuser »

I'm curious is the JIT developers could mention any Python features that prevent promising JIT features. An earlier Ken Jin blog [1], mentions how __del__ complicates reference counting optimization.

There is a story that Python is harder to optimize than, say, Typescript, with Python flexibility and the C API getting mentioned. Maybe, if the list of troublesome Python features was out there, programmers could know to avoid those features with the promise of activating the JIT when it can prove the feature is not in use. This could provide a way out of the current Python hard-to-JIT trap. It's just a gist of an idea, but certainly an interesting first step would be to hear from the JIT people which Python features they find troublesome.

[1] https://fidget-spinner.github.io/posts/faster-jit-plan.html

Post reply on HN