Re:Modern Python Performance Considerations
by chrisseaton on Thursday May 05, 2022 @01:36PM
(#31276293)
> This kills most potential optimizations, or even hard-code generation.
It doesn’t - this has been a basically solved problem since Self and deoptimisation were invented.
Re:Modern Python Performance Considerations
by Animats on Thursday May 05, 2022 @03:15PM
(#31277351)
In theory, yes. In CPython, apparently not. In PyPy, yes.[1] PyPy has to do a lot of extra work to permit some unlikely events.
Re:Modern Python Performance Considerations
by chrisseaton on Thursday May 05, 2022 @06:25PM
(#31279052)
You’re trying to correct me by posting my own mentee’s blog post at me.
Well, yes. In Python, one thread can monkey-patch the code in another thread while running. That feature is seldom used. In CPython, the data structures are optimized for that. Underneath, everything is a dict. This kills most potential optimizations, or even hard-code generation.
It's possible to deal with that efficiently. PyPy has a compiler, an interpreter, and something called the "backup interpreter", which apparently kicks in when the program being run starts doing weird stuff that requires doing everything in dynamic mode.
I proposed adding "freezing", immutable creation, to Python in 2010, as a way to make threads work without a global lock.[1] Guido didn't like it. Threads in Python still don't do much for performance.
[1] http://www.animats.com/papers/languages/pythonconcurrency.ht...