Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Python 3.11 vs 3.10 performance

github.com

Post reply on HN
Print view View original

51–60 of 460 posts

Re: Python 3.11 vs 3.10 performance

#51

Post by Wohlf »

woodruffw wrote: post #16
tasubotadas wrote: post #8

Cool improvement but changes very little when Python is x100 times slower than other GC languages.

This is probably the wrong comparison to make: Python is two orders of magnitude slower than compiled GC languages, but it's in the same order of magnitude as most other interpreted GC languages. (It actually changes a whole lot, because there's a whole lot of code already out there written in Python. 25% faster is still 25% faster, even if the code would have been 100x faster to begin with in another language.)

I thought Python was slower than many other interpreted languages but looking at some benchmark it turns out I was wrong.

It's about on par with Ruby, only Lua and JIT compiled runtimes beat it (for very understandable reasons).

Re: Python 3.11 vs 3.10 performance

#52

Post by simias »

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…

I suspect that the amount of people and especially companies willing to spend time and money optimizing Python are fairly low.

Think about it: if you have some Python application that's having performance issues you can either dig into a foreign codebase to see if you can find something to optimize (with no guarantee of result) and if you do get something done you'll have to get the patch upstream. And all that "only" for a 25% speedup.

Or you could rewrite your application in part or in full in Go, Rust, C++ or some other faster language to get a (probably) vastly bigger speedup without having to deal with third parties.

Re: Python 3.11 vs 3.10 performance

#54

Post by mywittyname »

uniqueuid wrote: post #15
MrYellowP wrote: post #10

Earlier quoted context omitted.

I don't wonder. For me it seems pretty clear. I believe the reason is that python does not need any low-hanging fruits to have people use it, which is why they're a priority for so many other projects out there. Low-hanging fruits attract people who can't reach higher than that. When talking about low-hanging fruits, it's important to consider who they're for. The intended target audience. It's important to ask ones…

I see your point, but it directly conflicts with the effort many people put into producing extremely fast libraries for specific purposes, such as web frameworks (benchmarked extensively), ORMs and things like json and date parsing, as seen in the excellent ciso8601 [1] for example. [1] https://github.com/closeio/ciso8601

Isn't this the point made in the last paragraph, about how people find ways around the limitations?

Re: Python 3.11 vs 3.10 performance

#55

Post by bilsbie »

alexfromapex wrote: post #36

One of the biggest features I'm looking forward to is the more specific error messages. I can't tell you how much time I've wasted with cryptic errors that just point to a line that has a list comprehension or similar.

When is that coming? Yes the error messages are confusing in a big list comprehension.

Re: Python 3.11 vs 3.10 performance

#56

Post by roelschroeven »

sod wrote: post #14

I wish there was something like llvm for scripting languages. Imagine if python, php, javascript, dart or ruby would not interpret the code themself, but compile to an interpretable common language, where you could just plug in the fastest interpreter there is for the job.

Is Perl's Parrot not meant to be something like that?

Re: Python 3.11 vs 3.10 performance

#57

Post by ChuckNorris89 »

int_19h wrote: post #27
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…

> one wonders why they haven't been a low-hanging fruit over the past 25 years. From the very page you've linked to: "Faster CPython explores optimizations for CPython. The main team is funded by Microsoft to work on this full-time. Pablo Galindo Salgado is also funded by Bloomberg LP to work on the project part-time."

Hmm, looks like corporate money gets sh*t done.

Re: Python 3.11 vs 3.10 performance

#58

Post by FartyMcFarter »

missblit wrote: post #18
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…

So we have: * Statically allocated ("frozen") core modules for fast imports * Avoid memory allocation for frames / faster frame creation * Inlined python functions are called in pure python without needing to jump through C * Optimizations that take advantage of speculative typing (Reminds me of Javascript JIT compilers -- though according to the FAQ Python isn't JIT yet) * Smaller memory usage for frames, objects, a…

> Inlined python functions are called in pure python without needing to jump through C

Given that Python is interpreted, it's quite unclear what this could mean.

Also, what does it mean to "call" an inlined function?? Isn't the point of inline functions that they don't get called at all?

Re: Python 3.11 vs 3.10 performance

#59

Post by dagmx »

tasubotadas wrote: post #8

Cool improvement but changes very little when Python is x100 times slower than other GC languages.

I feel this is a bit nihilistic.

Python is used in so many different areas, in some very critical roles.

Even a small speedup is going to be a significant improvement in metrics like energy use.

The pragmatic reality is that very few people are going to rewrite their Python code that works but is slow into a compiled language when speed of execution is trumped by ease of development and ecosystem.

Re: Python 3.11 vs 3.10 performance

#60

Post by dragonwriter »

sod wrote: post #14

I wish there was something like llvm for scripting languages. Imagine if python, php, javascript, dart or ruby would not interpret the code themself, but compile to an interpretable common language, where you could just plug in the fastest interpreter there is for the job.

There have been many attempts to do this, but the problem seems to be that a good target for one scripting language isn't necessarily a good target for another one with a different model, and the interest in a common backend isn't strong enough to overcome that.

(Though JS had some potential to do that by the power of it's browser role, before compiling interpreters to WASM became a better way of getting browser support than compiling another scripting language source to JS.)

Post reply on HN