Python 3.11 vs 3.10 performance

Post by coliveira » Wed, Jul 06, 2022, 8:35 PM UTC

mixmastamyk wrote: post #242

coliveira wrote: post #163

Earlier quoted context omitted.

Dynamic languages like Javascript have solved this problem by essentially caching the resolution of a particular expression that is executed very often. I don't see why this cannot be done in Python.

The expressions are dynamic, so they have to be evaluated every time. Python is excessively dynamic, so it can't (conventionally) be sped up as easily as many other languages unfortunately. Finally some folks are being paid and allowed to be working on it.

Post by everforward » Wed, Jul 06, 2022, 8:41 PM UTC

tambourine_man wrote: post #77

uniqueuid wrote: post #2

These speedups are awesome, but of course one wonders why they haven't been a low-hanging fruit over the past 25 years. Having read about some of the changes [1], it seems like the python core committers preferred clean over fast implementations and have deviated from this mantra with 3.11. Now let's get a sane concurrency story (no multiprocessing / queue / pickle hacks) and suddenly it's a completely different lang…

That’s something that has always puzzled me as well. Given the popularity, you’d think Python would have had several generations of JITs by now and yet it still runs interpreted, AFAIK. JavaScript has proven that any language can be made fast given enough money and brains, no matter how dynamic. Maybe Python's C escape hatch is so good that it’s not worth the trouble. It’s still puzzling to me though.

Post by tandav » Wed, Jul 06, 2022, 8:41 PM UTC

uniqueuid wrote: post #12

siekmanj wrote: post #6

Earlier quoted context omitted.

Python has actually had concurrency since about 2019: https://docs.python.org/3/library/asyncio.html . Having used it a few times, it seems fairly sane, but tbf my experience with concurrency in other languages is fairly limited. edit: ray https://github.com/ray-project/ray is also pretty easy to use and powerful for actual parallelism

I have used asyncio in anger quite a bit, and have to say that it seems elegant at first and works very well for some use cases. But when you try to do things that aren't a map-reduce or Pool.map() pattern, it suddenly becomes pretty warty. E.g. scheduling work out to a processpool executor is ugly under the hood and IMO ugly syntactically as well.

Post by citrin_ru » Wed, Jul 06, 2022, 8:48 PM UTC

metadat wrote: post #237

BerislavLopac wrote: post #229

Earlier quoted context omitted.

The GIL removal by that guy reverted some of the improvement done by other optimisations, so the overall improvement was much smaller. And most people do care for single-threaded speed, because the vast majority of Python software is written as single-threaded.

> the vast majority of Python software is written as single-threaded. This is a self-fulfilling prophecy, as the GIL makes Python's (and Ruby's) concurrency story pretty rough compared to nearly all other widely used languages: C, C++, Java, Go, Rust, and even Javascript (as of late).

Post by staticassertion » Wed, Jul 06, 2022, 8:51 PM UTC

mjw1007 wrote: post #95

staticassertion wrote: post #65

Earlier quoted context omitted.

Guido stepping away from the language will have a lot of impact on changes that were culturally guided.

Guido is one of the people leading the current performance efforts.