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

221–230 of 330 posts

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

#221

Post by mathisfun123 »

coldtea wrote: post #203
mathisfun123 wrote: post #170

Earlier quoted context omitted.

> same member value within the same function body are stable Did you miss the part where I explained to you there's no way to identify that it's a member variable? > Nobody in the real world expects this behaviour As has already been explained to you by a sibling comment you are in fact wrong and there are in fact plenty of people in the real world who do actually expect this behavior. So I'll repeat myself: lots of…

The above is a very thick response that doesn't address the parent's points, just sweeps them under the rag with "that's just how it was designed/it works". "Did you miss the part where I explained to you there's no way to identify that it's a member variable?" No, you you did miss the case where that in itself can be considered nuts - or at least an unfortunate early decision. "this just how things are dunn around d…

> considered nuts - or at least an unfortunate early decision

Please explain to us then how exactly you would infer a variable with an arbitrary name is actually a reference to the class instance in an interpreted language.

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

#222

Post by philipallstar »

cpburns2009 wrote: post #25
ekjhgkejhgk wrote: post #3

Doesn't PyPy already have a jit compiler? Why aren't we using that?

PyPy is limited to maintenance mode due to a lack of funding/contributors. In the past, I think a few contributors or funding is what helped push "minor" PyPy versions. It's too bad PyPy couldn't take the federal funding the PSF threw away.

> It's too bad PyPy couldn't take the federal funding the PSF threw away.

The PSF is primarily a political advocacy organisation, so it wouldn't make sense for them to use the money for Python.

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

#224

Post by 1718627440 »

josefx wrote: post #215
cherryteastain wrote: post #201

Earlier quoted context omitted.

OOP has nothing to do with it. In your C++ example, foo(bar const&); is basically the same as bar.foo();. At the end of the day, whether passing it in as an argument or accessing this via the method call syntax it's just a pointer to a struct. Not to mention, a C++ compiler can, and often does, choose to put even references to member variables in registers and access them that way within the method call. This is a Py…

> This is a Python specific problem caused by everything being boxed I would say it is part python being highly dynamic and part C++ being full of undefined behavior. A c++ compiler will only optimize member access if it can prove that the member isn't overwritten in the same thread. Compatible pointers, opaque method calls, ... the list of reasons why that optimization can fail is near endless, C even added the rest…

What is going on here is not, that an attribute might be changed concurrently and the interpreter can't optimize the access. That is also a consideration. But the major issue is that an attribute doesn't really refer to a single thing at all, but instead means whatever object is returned by a function call that implements a string lookup. __getattr__ is not an implementation detail of the language, but something that an object can implement how it wants to, just like __len__ or __gt__. It's part of the object behaviour, not part of the static interface. This is a fundamental design goal of the Python language.

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

#225

Post by vanderZwan »

anematode wrote: post #166
dekelpilli wrote: post #149

Earlier quoted context omitted.

Java also has a performance cost to accessing class fields, as exampled by this (now-replaced) code in the JDK itself - https://github.com/openjdk/jdk/blob/jdk8-b120/jdk/src/share/...

Any decent JIT compiler (and HotSpot's is world class) will optimize this out. Likely this was done very early on in development, or was just to reduce bytecode size to promote inlining heuristics that use it

String is also a pretty damn fundamental object, and I'm sure trim() calls are extremely common too. I wouldn't be surprised if making sure that seemingly small optimizations like this are applied in the interpreter before the JIT kicks are not premature optimizations in that context.

There might be common scenarios where this had a real, significant performance impacts, E.G. use-cases where it's such a bottle-neck in the interpreter that it measurably affects warm-up time. Also, string manipulation seems like the kind of thing you see in small scripts that end before a JIT even kicks in but that are also called very often (although I don't know how many people would reach for Java in that case.

EDIT: also, if you're a commercial entity trying to get people to use your programming language, it's probably a good idea to make the language perform less bad with the most common terrible code. And accidentally quadratic or worse string manipulation involving excessive calls to trim() seems like a very likely scenario in that context.

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

#226

Post by marcyb5st »

jmspring wrote: post #121
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.

still GIL

Opt-in starting from 3.15, or am I mistaken?

Anyway you can already try freethreaded builds that have the GIL disabled, but my experience is that most of your dependencies won't work.

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

#227

Post by 1718627440 »

coldtea wrote: post #203
mathisfun123 wrote: post #170

Earlier quoted context omitted.

> same member value within the same function body are stable Did you miss the part where I explained to you there's no way to identify that it's a member variable? > Nobody in the real world expects this behaviour As has already been explained to you by a sibling comment you are in fact wrong and there are in fact plenty of people in the real world who do actually expect this behavior. So I'll repeat myself: lots of…

The above is a very thick response that doesn't address the parent's points, just sweeps them under the rag with "that's just how it was designed/it works". "Did you miss the part where I explained to you there's no way to identify that it's a member variable?" No, you you did miss the case where that in itself can be considered nuts - or at least an unfortunate early decision. "this just how things are dunn around d…

> No, you you did miss the case where that in itself can be considered nuts - or at least an unfortunate early decision.

This is not a side implementation detail, that they got wrong, this is a fundamental design goal of Python. You can find that nuts, but then just don't use Python, because that is (one of) that things, that make Python Python.

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

#228

Post by PurpleRamen »

Tempest1981 wrote: post #123
scorpioxy wrote: post #119

Earlier quoted context omitted.

I wasn't aware that migrating projects off Cobol has become cheap and it would only take a Claude subscription. In my experience, the problem had always been maintaining the business logic and any integrations with third-party software that also may be running legacy code-bases or have been abandoned. It can get quite complicated, from what I've seen. Now of course if you're talking about well maintained code-bases w…

IBM shares fell 13% in a single day in last month: "IBM Sinks Most Since 2000 as Anthropic Touts Cobol Tool" https://finance.yahoo.com/news/ibm-sinks-most-since-2000-210... It may not be "cheap", but possibly cheaper than IBM's consulting.

Share-pricing operates on illusions. Just selling a plausible claim can influence the price. Whether they will deliver at the end, doesn't matter at that moment.

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

#229

Post by kenjin4096 »

adrian17 wrote: post #7

I'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 resul…

> I've never seen where the high level discussions were happening

Thanks for your interest. This is something we could improve on. We were supposed to document the JIT better in 3.15, but right now we're crunching for the 3.15 release. I'll try to get to updating the docs soon if there's enough interest. PEP 744 does not document the new frontend.

I wrote a somewhat high-level overview here in a previous blog post https://fidget-spinner.github.io/posts/faster-jit-plan.html#...

> does this mean each opcode is possibly split into two (or more?) stencils, with and without removed increfs/decrefs?

This is a great question, the answer is not exactly! The key is to expose the refcount ops in the intermediate representation (IR) as one single op. For example, BINARY_OP becomes BINARY_OP, POP_TOP (DECREF), POP_TOP (DECREF). That way, instead of optimizing for n operations, we just need to expose refcounting of n operations and optimize only 1 op (POP_TOP). Thus, we just need to refactor the IR to expose refcounting (which was the work I divided up among the community).

If you have any more questions, I'm happy to answer them either in public or email.

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

#230

Post by 1718627440 »

mattclarkdotnet wrote: post #144
Izkata wrote: post #137

Earlier quoted context omitted.

Execution time, not parse time. It's a side effect of function declarations being statements that are executed, not the list/dict itself. It would happen with any object.

It's still ridiculous. A hypothetical Python4 would treat function declarations as declarations not executable statements, with no impact on real world code except to remove all the boilerplate checks.

You are describing a completely different language, that differs in very major ways from Python. You can of course create that, but please don't call it Python 4 !
Post reply on HN