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

301–310 of 330 posts

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

#301

Post by stmw »

simonask wrote: post #49
stmw wrote: post #20

Earlier quoted context omitted.

Some languages are much harder to compile well to machine code. Some big factors (for any languages) are things like: lack of static types and high "type uncertainty", other dynamic language features, established inefficient extension interfaces that have to be maintained, unusual threading models...

The simplest JIT just generates the machine code instructions that the interpreter loop would execute anyway. It’s not an extremely difficult thing, but it also doesn’t give you much benefit. A worthwhile JIT is a fully optimizing compiler, and that is the hard part. Language semantics are much less important - dynamic languages aren’t particularly harder here, but the performance roof is obviously just much lower.

Agree re: different types of JITs producing wildly different results but don't agree about language semantics - even a Java JIT has to give up speed due to certain seemingly minor language and JVM issues. So both matter - no matter how good of a compiler engineer you are, some semantics are just not optimizable. Indeed, the use of a "trace JITs" is a proof of that.

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

#302

Post by xenadu02 »

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

> it is nuts that in an object method, there is a performance enhancement through caching a member value i don't understand what you think is nuts about this. it's an interpreted language and the word `self` is not special in any way (it's just convention - you can call the first param to a method anything you want). so there's no way for the interpreter/compiler/runtime to know you're accessing a field of the class…

If you dig into JS engine implementations they deal with a lot of the same sorts of things. Simple objects with straightforward properties are tagged such that they skip the dynamic machinery with fallback paths to deal with dynamism when it is necessary.

A common approach is hidden classes that work much like classes in other languages. Reading a simple int property just reads bytes at an offset from the object pointer directly. Upon entry to the method bits of the object are tested and if the object is not known to be simple it escapes into the full dynamic machinery.

I don't know if those exact techniques would work for Python but this is not an either-or situation.

See also: modern Objective-C msg_Send which is so fast on modern hardware for the fast-path it is rarely a performance bottleneck. Despite being able to add dynamic subclasses or message forward at runtime.

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

#303

Post by LtWorf »

bmm6o wrote: post #288
LtWorf wrote: post #261

Earlier quoted context omitted.

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.

Except python has a well documented global lock.

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

#304

Post by 12_throw_away »

seanw444 wrote: post #284
qy-mj wrote: post #223

[flagged]

Jumping 12 major versions to one that doesn't exist yet must yield quite the performance boost.

After installing all released versions of python locally, I can confirm that the `python3.15` command is not only very fast, but is guaranteed not to diverge!

   $ time python3.15 -c "while True: print('hello world')"
   bash: python3.15: command not found

   real 0m0.005s
   user 0m0.000s
   sys 0m0.002s

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

#305

Post by mathisfun123 »

coldtea wrote: post #274
NetMageSCW wrote: post #262

Earlier quoted context omitted.

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?

ok then be the change you want to see in the world and send a PR instead of just proclaiming things lololol

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

#306

Post by anematode »

LtWorf wrote: post #303
bmm6o wrote: post #288

Earlier quoted context omitted.

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.

Except python has a well documented global lock.

This thread is discussing Java, not Python

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

#307

Post by rtpg »

teleforce wrote: post #283
rtpg wrote: post #159

Earlier quoted context omitted.

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

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

I regret to inform you that there are _loads_ of multi-decades-old Python stacks at this point.

On the micro level I'll be like "ugh wish I wasn't paying the costs of Python" decently enough. But on the macro level I don't regret Python stacks. At least not when looking at the alternatives.

Tho I will admit I'm a bit mystified at data science stuff in particular persisting in Python. Lots of CPU churn even if the underlying libs are all C extensions.

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

#308

Post by simonask »

stmw wrote: post #301
simonask wrote: post #49

Earlier quoted context omitted.

The simplest JIT just generates the machine code instructions that the interpreter loop would execute anyway. It’s not an extremely difficult thing, but it also doesn’t give you much benefit. A worthwhile JIT is a fully optimizing compiler, and that is the hard part. Language semantics are much less important - dynamic languages aren’t particularly harder here, but the performance roof is obviously just much lower.

Agree re: different types of JITs producing wildly different results but don't agree about language semantics - even a Java JIT has to give up speed due to certain seemingly minor language and JVM issues. So both matter - no matter how good of a compiler engineer you are, some semantics are just not optimizable. Indeed, the use of a "trace JITs" is a proof of that.

This is orthogonal to the difficulty of actually implementing a JIT compiler.

It’s very much possible to make something less advanced than JVM or CLR, or even V8, that will still outperform an interpreter, even for an extremely dynamic language like Python.

As others have mentioned, the roadblock here is that interpreter internals are too public, so doing it without breaking the C API that extensions use is really hard.

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

#309

Post by zadikian »

cpgxiii wrote: post #279
zarzavat wrote: post #187

Earlier quoted context omitted.

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

> The big benefit is that you get concurrency without the overhead of multi-process.

Bigger thing imo is that multiprocessing is just really annoying. In/out has to be pickleable, anything global gets rerun in each worker which often requires code restructuring, it doesn't work with certain frameworks, and other weird stuff happens with it.

Post reply on HN