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

271–280 of 330 posts

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

#271

Post by ehutch79 »

scorpioxy wrote: post #119
eru wrote: post #116

Earlier quoted context omitted.

> 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. Slight tangent: if Claude can decimate IBM stock price by migrating off Cobol for cheap, surely we can do Python 2 to 3 now, too? About the internals: we sort of missed an opportunity there, but back then there also didn't quite know what they were doing (or at least we have bette…

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…

> I wasn't aware that migrating projects off Cobol has become cheap and it would only take a Claude subscription.

It's like you never even saw u/bumlazer42069's seminal post that 'itd only take 3 prompts and a weekend for me to port all that cobol to typescript'

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

#272

Post by JodieBenitez »

kccqzy wrote: post #91
JodieBenitez wrote: post #85

Earlier quoted context omitted.

Pretty much my thoughts the other day... now that Codex does the writing, maybe I can finally switch to Go for the web backend stuff without being annoyed by some of its archaisms and gain significant execution performance, while still having a relatively easy to read language.

You ask a machine to write your code and you still care about being easy to read? In my experience the people who care the most about code readability tend to be the people most opinionated on having the right abstractions, which are historically not available in Go.

> You ask a machine to write your code and you still care about being easy to read?

I just happen to read what the machine writes, which is a way to both learn and inspect. So yes, I care about the code being relatively (and I stress relatively) easy to read. Go is ok there.

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

#273

Post by rurban »

wolvesechoes wrote: post #209
stabbles wrote: post #205

Earlier quoted context omitted.

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 prov…

Because the python devs weren't allowed to optimize on types. They are only hints, not contracts. If they become contracts, it will get 5-10x faster. But `const` would be more important than core types.

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

#274

Post by coldtea »

NetMageSCW wrote: post #262
coldtea wrote: post #236

Earlier quoted context omitted.

>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. Did I stutter when I wrote about "an unfortunate early decision"? Who said it has to be "an arbitrary name"? Even so, you could add a bloody marker announcing an arbitrary name (which 99% would be self anyway) as so, as an instruction to the interpreter. If…

But now you are no longer talking about the way Python works, but the way you want Python to work - and that has nothing to do with Python.

"The way our economy works is bad"

"That's how it's been since forever, it's an essential part of country X"

"Yes, and it's a badly designed part".

"But now you are no longer talking about the way country X works, but the way you want country X to work - and that has nothing to do with country X."

See how the argument quickly degenerates?

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

#275

Post by phkahler »

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.

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

#276

Post by Ardren »

gpderetta wrote: post #249
1718627440 wrote: post #218

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. There is no such thing as 'successive references to the same member value' here. It's not that you look up the same object and it can change, it's that you are not referring to th…

ok, then it is nuts that __getattr__ (itself a specially blessed function) is not required to be pure at least from the caller point of view.

If it was it wouldn't be Python. It can never be pure because __getattr__ is just another method that anyone can overwrite.

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

#277

Post by cpgxiii »

mattip wrote: post #153
cpgxiii wrote: post #102

Earlier quoted context omitted.

> In practice CPython reliably calls it cuz it reference counts ... In a world where more people were using PyPy we could have pressure from that perspective to avoid leaning into it A big part of the problem is that much of the power of the Python ecosystem comes specifically from extensions/bindings written in languages with manual (C) or RAII/ref-counted (C++, Rust) memory management, and having predictable Python…

That cleanup can be explicit when needed by using context managers. Mixing resource handling with object lifetime is a bad design choice

> That cleanup can be explicit when needed by using context managers.

It certainly can be, but if a large part of the Python code you are writing involves native objects exposed through bindings then using context managers everywhere results in an incredible mess.

> Mixing resource handling with object lifetime is a bad design choice

It is a choice made successfully by a number of other high-performance languages/runtimes. Unfortunately for Python-the-language, so much of the utility of Python-the-ecosystem depends on components written in those languages (unlike, for example, JVM or CLR languages where the runtime is usually fast enough to require a fairly small portion of non-managed code).

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

#278

Post by skitter »

gpderetta wrote: post #250
Someone wrote: post #179

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. The language supports multiple threads and doesn’t have private fields ( https://docs.python.org/3/tutorial/classes.html#private-vari... ), so the runtime cannot rule out that the value gets changed in-between. And yes, it often is obvious to humans that’s not intended to…

wouldn't a concurrent change without synchronization be UB anyway? Also parent wants to cache the address, not the value (but you have to cache the value if you want to optimize manually)

Why would it be UB? All objects are behind (thin) pointers, which can be overwritten atomically.

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

#279

Post by cpgxiii »

zarzavat wrote: post #187
cpgxiii wrote: post #105

Earlier quoted context omitted.

> 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. Way more than 1% of the community, particularly of the community actively developing Python, wants free-threaded. The problem here is that the Python community consists of several different groups: 1. Basically pure Python code with no threadin…

Where is the major win? Sorry but I just don't see the use case for free-threading. Native code can already be multi-threaded so if you are using Python to drive parallelized native code, there's no win there. If your Python code is the bottleneck, well then you could have subinterpreters with shared buffers and locks. If you really need to have shared objects, do you actually need to mutate them from multiple interp…

> Native code can already be multi-threaded so if you are using Python to drive parallelized native code, there's no win there.

When using something like boost::python or pybind11 to expose your native API in Python, it is not uncommon to have situations where the native API is extensible via inheritance or callbacks (which are easy to represent in these binding tools). Today with the GIL you are effectively forced to choose between exposing the native API parallelism or exposing the native API extensibility; e.g. you can expose a method that performs parallel evaluation of some inputs, OR you can expose a user-provided callback to be run on the output of each evaluation, but you cannot evaluate those inputs and run a user-provided callback in parallel.

The "dumbest" form of this is with logging; people want to redirect whatever logging the native code may perform through whatever they are using for logging in Python, and that essentially creates a Python callback on every native logging call that currently requires a GIL acquire/release.

Could some of this be addressed with various Python-specific workarounds/tools? Probably. But doing so is probably also going to tie the native code much more tightly to problematic/weird Pythonisms (in many cases, the native library in question is an entirely standalone project).

> The only thing that free threading gives you is concurrent mutations to Python objects, which is like, whatever.

The big benefit is that you get concurrency without the overhead of multi-process. Shared memory is always going to be faster than having to serialize for inter-process communication (let alone that not all Python objects are easily serializable).

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

#280

Post by germandiago »

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.

I share your view. Python's flexibility is central to Python.

Even type annotations, though useful, can get in the way for certain tasks.Betting on things like these to speed up things would be a mistake, since it would kind of force you to follow that style.

Anything that accelearates things should rely on run-time data, not on type annotations that won't change.

Post reply on HN