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

201–210 of 330 posts

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

#201

Post by cherryteastain »

codesnik wrote: post #168
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…

basically all object oriented languages work like that. You access a member; you call a method which changes that member; you expect that change is visible lower in the code, and there're no statically computable guarantees that particular member is not touched in the called method (which is potentially shadowed in a subclass). It's not dynamism, even c++ works the same, it's an inherent tax on OOP. All you can do is…

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 Python specific problem caused by everything being boxed by default and the interpreter does not even know what's in the box until it dereferences it, which is a problem that extends to the "self" object. In contrast in C++ the compiler knows everything there's to know about the type of this which avoids the issue.

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

#202

Post by thaumasiotes »

Marazan wrote: post #198
Tempest1981 wrote: post #123

Earlier quoted context omitted.

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.

IBM share price is back to where it was pre-Anthropic press release.

Sure, but imagine how much higher it would have gone in the counterfactual world where Anthropic didn't have an automatic port-from-Cobol tool.

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

#203

Post by coldtea »

mathisfun123 wrote: post #170
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…

> 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 diz here parts" is not an argument.

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

#204

Post by Revisional_Sin »

zahlman wrote: post #175
mattclarkdotnet wrote: post #133

Earlier quoted context omitted.

Oh, and while we're at it, fix the "empty array is instantiated at parse time so all your functions with a default empty array argument share the same object" bullshit.

We don't call them "arrays". It has nothing to do with whether the list is empty. It has nothing to do with lists at all. It's the behaviour of default arguments. It happens at the time that the function object is created, which is during runtime. You only notice because lists are mutable. You should already prefer not to mutate parameters, and it especially doesn't make sense to mutate a parameter that has a default…

It's best practice to avoid mutable defaults even if you're not planning to mutate the argument.

It's just slightly annoying having to work around this by defaulting to None.

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

#205

Post by stabbles »

wolvesechoes wrote: post #199
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…

> Python really needs to take the Typescript approach of "all valid Python4 is valid Python3" It is called type hints, and is already there. TS typing doesn't bring any perf benefits over plain JS.

You really need dedicated types for `int64` and something like `final`. Consider:

    class Foo:
      __slots__ = ("a", "b")
      a: int
      b: float
there are multiple issues with Python that prevent optimizations:

* a user can define subtype `class my_int(int)`, so you cannot optimize the layout of `class Foo`

* the builtin `int` and `float` are big-int like numbers, so operations on them are branchy and allocating.

and the fact that Foo is mutable and that `id(foo.a)` has to produce something complicates things further.

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

#206

Post by Maxion »

thaumasiotes wrote: post #202
Marazan wrote: post #198

Earlier quoted context omitted.

IBM share price is back to where it was pre-Anthropic press release.

Sure, but imagine how much higher it would have gone in the counterfactual world where Anthropic didn't have an automatic port-from-Cobol tool.

Remember that those who trade on the stock market are not programmers with decades of experience writing cobol.

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

#207

Post by Kamii0909 »

dekelpilli wrote: post #149
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

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/...

That was a niche optimization primarily targeting code at intepretor. Even the most basic optimizing compiler in HotSpot tiered compilation chain at that time (the client compiler or C1) would be able to optimize that into the register. Since String is such an important class, even small stuffs like this is done.

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

#208

Post by zeratax »

mattclarkdotnet wrote: post #133
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…

Oh, and while we're at it, fix the "empty array is instantiated at parse time so all your functions with a default empty array argument share the same object" bullshit.

there is PEP 671 for that, which introduces extra syntax for the behavior you want. people rely on the current behavior so you can't really change it

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

#209

Post by wolvesechoes »

stabbles wrote: post #205
wolvesechoes wrote: post #199

Earlier quoted context omitted.

> Python really needs to take the Typescript approach of "all valid Python4 is valid Python3" It is called type hints, and is already there. TS typing doesn't bring any perf benefits over plain JS.

You really need dedicated types for `int64` and something like `final`. Consider: class Foo: __slots__ = ("a", "b") a: int b: float there are multiple issues with Python that prevent optimizations: * a user can define subtype `class my_int(int)`, so you cannot optimize the layout of `class Foo` * the builtin `int` and `float` are big-int like numbers, so operations on them are branchy and allocating. and the fact tha…

Maybe, but I quoted specific part I was replying to. TS has no impact on runtime performance of JS. Type hints in Python have no impact on runtime performance of Python (unless you try things like mypyc etc; actually, mypy provides `from mypy_extensions import i64`)

Therefore Python has no use for TS-like superset, because it already has facilities for static analysis with no bearing on runtime, which is what TS provides.

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

#210

Post by fleetfox »

ecshafer wrote: post #12

What is wrong with the Python code base that makes this so much harder to implement than seemingly all other code bases? Ruby, PHP, JS. They all seemed to add JITs in significantly less time. A Python JIT has been asked for for like 2 decades at this point.

I can't really talk about Ruby. But PHP is much more static and surface of things you have to care about at runtime is like magnitude smaller and there already was opache as a starting point. And speaking of something like JIT in V8 is of the most sophisticated and complicated ever built. There hasn't been near enough man hours and funding to cpython to make it fair comparison
Post reply on HN