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

281–290 of 330 posts

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

#281

Post by germandiago »

rich_sasha wrote: post #136
mattclarkdotnet wrote: post #125

Python really needs to take the Typescript approach of "all valid Python4 is valid Python3". And then add value types so we can have int64 etc. And allow object refs to be frozen after instantiation to avoid the indirection tax. Sensible type-annotated python code could be so much faster if it didn't have to assume everything could change at any time. Most things don't change, and if they do they change on startup (e…

I think sadly a lot of Python in the wild relies heavily, somewhere, on the crazy unoptimisable stuff. For example pytest monkey patches everything everywhere all the time. You could make this clean break and call it Python 4 but frankly I fear it won't be Python anymore.

If you do that you then have a less productive language for many use cases IMHO.

All the dynamism from Python should stay where it is.

Just JIT and remember a type maybe, but do not force a type from a type hint or such things.

As a minimum, I would say not relying on that is the correct thing. You could exploit it, but not force it to change the semantics.

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

#282

Post by germandiago »

zahlman wrote: post #177
mattclarkdotnet wrote: post #146

Earlier quoted context omitted.

Let's not get started on the cached shared object refs for small integers....

What realistic use case do you have for caring about whether two integers of the same value are distinct objects? Modern versions of Python warn about doing unpredicatble things with `is` exactly because you are not supposed to do those things. Valid use cases for `is` at all are rare.

if v is not None as opposed to if not v is one of those use cases if you store 0 or False or an empty list, etc.

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

#283

Post by teleforce »

rtpg wrote: post #159
mattclarkdotnet wrote: post #154

Earlier quoted context omitted.

What's nuts is that the language doesn't guarantee that successive references to the same member value within the same function body are stable. You can look it up once, go off and do something else, and look it up again and it's changed. It's dynamism taken to an unnecessary extreme. Nobody in the real world expects this behaviour. Making it just a bit less dynamic wouldn't change the fundamentals of the language bu…

In Python attribute access aren't stable! `self.x` where `x` is a property is not guaranteed to refer to the same thing. And getting rid of descriptors would be a _fundamental change to the language_. An immeense one. Loads of features are built off of descriptors or descriptor-like things. And what you're complaining about is also not true in Javascript world either... I believe you can build descriptor-like things…

>Remember, this is a scripting language, not a compiled language

This is the fundamental issue and "elephant in the room" that everyone is seems to be overlooking, and putting under the carpet.

The extreme compiled type language guys going gung-ho with very slow to compile and complicated Rust (moreso than C++), while the rest of the world gladly hacking their shiny ML/AI codes in scripting language aka Python "the glue duct tapes language" with most if not all the fast engine libraries (e.g PyTorch) written in unsafe C/C++.

The problem is that Python was meant for scripting not properly designed software system engineering. After all it's based on ABC language for beginners with an asterisk attached "intended for teaching or prototyping, but not as a systems-programming language" [1].

In ten years time people will most probably look in horror at their python software stacks tech debt that they have to maintain for the business continuity. Or for their own sanity, they will rewrite the entire things in much more stable with fast development and compiled modern language eco-system like D language with native engine libraries, and seamless integration C, and C++ (to some extend) if necessary.

[1] ABC (programming language)

https://en.wikipedia.org/wiki/ABC_(programming_language)

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

#285

Post by 0xffff2 »

drob518 wrote: post #253
oblio wrote: post #248

Earlier quoted context omitted.

I feel that this excuse is being trotted out too much. Most engineers never get to choose the programming language used for 90% of their professional projects. And when Python is a mainstream language on top of which large, globally known websites, AI tools, core system utilities, etc are built, we should give up the purity angle and be practical. Even the new performance push in Python land is a reflection of this.…

You’re always free to create your own Python-like language that caters more toward your goals. No excuses, then.

This is not a substantive response to

> Most engineers never get to choose the programming language used for 90% of their professional projects.

If it was up to me, there are plenty of languages to choose from that meet my technical needs just fine, but the political friction of getting all of my colleagues (most of whom are not software engineers at all) to use my language of choice is entirely insurmountable. Therefore, I have a vested interested in seeing practical changes to Python. The existence or invention of other languages is irrelevant.

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

#286

Post by 0xffff2 »

phkahler wrote: post #275
mattclarkdotnet wrote: post #125

Python really needs to take the Typescript approach of "all valid Python4 is valid Python3". And then add value types so we can have int64 etc. And allow object refs to be frozen after instantiation to avoid the indirection tax. Sensible type-annotated python code could be so much faster if it didn't have to assume everything could change at any time. Most things don't change, and if they do they change on startup (e…

>> Sensible type-annotated python code could be so much faster if it didn't have to assume everything could change at any time. Then it wouldn't be Python any more.

Fine by me. I don't particularly like Python, but it's the defacto standard in my field so I have to use it (admittedly this is an improvement over a decade ago, when MATLAB was the defacto standard). I don't care about preserving the spirit of Python, I just care that the thing that bears the name Python meets my needs.

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

#287

Post by dundarious »

1718627440 wrote: post #233
mattclarkdotnet wrote: post #132

Earlier quoted context omitted.

To clarify, it is nuts that in an object method, there is a performance enhancement through caching a member value. class SomeClass def init(self) self.x = 0 def SomeMethod(self) q = self.x ## do stuff with q, because otherwise you're dereferencing self.x all the damn time

This is not just a performance concern, this describes completely different behaviour. You forgot that self.x is just Class.__getattr__(self, 'x') and that you can implement __getattr__ how you like. There is no object identity across the values returned by __getattr__.

This level of dynamism is commonly forgotten/omitted because it is most often not at all needed. "There is no object identity across the values [retrieved by self.x]" is a very curious choice to many.

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

#288

Post by bmm6o »

LtWorf wrote: post #261
anematode wrote: post #186

Earlier quoted context omitted.

If what you call gets inlined, then the compiler can see that it either does or doesn't modify the attribute and optimize it accordingly. Even virtual calls can often be inlined via, e.g., class hierarchy analysis and inline caches. If these analyses don't apply and the callee could do anything, then of course the compiler can't keep the value hoisted. But a function call has to occur anyway, so the hoisted value wil…

Another thread can access it and do that, how could the compiler possibly know about it?

There are documented ways to ensure that changes are visible across threads (e.g. locks). If these are not used, the compiler is within its rights to not go out of its way to pull changes from another thread.

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

#289

Post by 1718627440 »

dundarious wrote: post #287
1718627440 wrote: post #233

Earlier quoted context omitted.

This is not just a performance concern, this describes completely different behaviour. You forgot that self.x is just Class.__getattr__(self, 'x') and that you can implement __getattr__ how you like. There is no object identity across the values returned by __getattr__.

This level of dynamism is commonly forgotten/omitted because it is most often not at all needed. "There is no object identity across the values [retrieved by self.x]" is a very curious choice to many.

It's very Pythonic to expose e.g. state via the existence of attributes. This also makes it possible to dynamically expose foreign language interfaces. You can really craft the interface you like, because the interface exposal is also normal code that returns strings and objects.

You are right that it is not needed often, but there is often somewhere a part in the library stack that does exactly this, to expose a nice interface.

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

#290

Post by fwip »

thaumasiotes wrote: post #200
zahlman wrote: post #177

Earlier quoted context omitted.

What realistic use case do you have for caring about whether two integers of the same value are distinct objects? Modern versions of Python warn about doing unpredicatble things with `is` exactly because you are not supposed to do those things. Valid use cases for `is` at all are rare.

> Valid use cases for `is` at all are rare. There might not be that many of them, depending on how you count, but they're not rare in the slightest. For example, you have to use `is` in the common case where you want the default value of a function argument to be an empty list.

Could you expand on this? For example, this works just fine:

    def silly_append(item, orig=[]):
       return orig + [item]
Edit: Oh, I think you probably mean in cases where you're mutating the input list.
Post reply on HN