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

171–180 of 460 posts

Re: Python 3.11 vs 3.10 performance

#171

Post by winstonewert »

DasIch wrote: post #129
winstonewert wrote: post #108

Earlier quoted context omitted.

> You should probably read the full context around that quote, I'm sick and tired of everyone repeating it mindlessly: I'm confused. What do you think the context changes? At least as I read it, both the short form and full context convey the same idea.

I agree with you, the context changes nothing (and I upvoted you for this reason). However programming languages and infrastructure pieces like this are a bit special, in that optimizations here are almost never premature. * Some of the many applications relying on these pieces, could almost certainly use the speedup and for those it wouldn't be premature * The return of investment is massive due to the scale * There…

I don't know about that. Even with your programming language/infrastructure you still want to identify the slow bits and optimize those. At the end of the day, you only have a certain amount of bandwith for optimization, and you want to use that where you'll get the biggest bang for you buck.

Re: Python 3.11 vs 3.10 performance

#172

Post by nestorD »

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.

This is already a thing, LLVM has a JIT interface which is used by the Julia interpreter.

Re: Python 3.11 vs 3.10 performance

#173

Post by polski-g »

teekert wrote: post #161
bilsbie wrote: post #55

Earlier quoted context omitted.

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

Whenever I nest a list comprehension I feel dirty anyway, I wonder if a better error message will help solve something that is just hard to grasp sometimes.

All list comprehensions should error with message "FATAL PARSE ERROR: Will you really understand this in six months?"

Re: Python 3.11 vs 3.10 performance

#174

Post by winstonewert »

bshipp wrote: post #168
GrayShade wrote: post #122

Earlier quoted context omitted.

That quote has been thrown around every time in order to justify writing inefficient code and never optimizing it. Python is 10-1000x slower than C, but sure, let's keep using it because premature optimization is the root of all evil, as Knuth said. People really love to ignore the "premature" word in that quote. Instead, what he meant is that you should profile what part of the code is slow and focus on it first. Kn…

You certainly can accept that slowdown if the total program run-time remains within acceptable limits and the use of a rapid prototyping language reduces development time. There are times when doing computationally heavy, long-running processes where speed is important, but if the 1000x speedup is not noticeable to the user than is it really a good use of development time to convert that to a more optimized language?…

I would note that the choice of programming language is a bit different. Projects are pretty much locked into that choice. You've got to decide upfront whether the trade off in a rapid prototyping language is good or not, not wait until you've written the project and then profile it.

Re: Python 3.11 vs 3.10 performance

#175

Post by agumonkey »

bilsbie wrote: post #55
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.

In a way it's a nice incentive not to nest too much (I have that tendency too)

Re: Python 3.11 vs 3.10 performance

#176

Post by bshipp »

winstonewert wrote: post #174
bshipp wrote: post #168

Earlier quoted context omitted.

You certainly can accept that slowdown if the total program run-time remains within acceptable limits and the use of a rapid prototyping language reduces development time. There are times when doing computationally heavy, long-running processes where speed is important, but if the 1000x speedup is not noticeable to the user than is it really a good use of development time to convert that to a more optimized language?…

I would note that the choice of programming language is a bit different. Projects are pretty much locked into that choice. You've got to decide upfront whether the trade off in a rapid prototyping language is good or not, not wait until you've written the project and then profile it.

Certainly, but Python is flexible enough that it readily works with other binaries. If a specific function is slowing down the whole project, an alternate implementation of that function in another language can smooth over that performance hurdle. The nice thing about Python is that it is quite happy interacting with C or go or Fortran libraries to do some of the heavy lifting.

Re: Python 3.11 vs 3.10 performance

#177

Post by d23 »

upupandup wrote: post #80
bilsbie wrote: post #53

I’d be curious to see the speed up compared to python 2.4. To see how far it’s come since I first got started with it.

it means you are not following PEP8 if you get non descriptive errors, it means you haven't followed proper exception handling/management its not the fault of Python but the developer. go ahead and downvote me but you if you mentioned parent's comment in an interview, you would not receive a call back or at least I hope the interviewer is realizing the skill gap.

I think this is both insulting and not even responding to the right comment.

Re: Python 3.11 vs 3.10 performance

#178

Post by cglace »

fmakunbound wrote: post #146
tasubotadas wrote: post #8

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

This was my immediate thought when I looked at the numbers, but I didn't want to be "that guy". I think if all you ever work in is Python, it's still nice even if it is a tiny improvement.

The goal with faster cpython is for small compounding improvements with each point release[0]. So in the end it should be much more than a tiny improvement.

[0] https://github.com/markshannon/faster-cpython/blob/master/pl...

Re: Python 3.11 vs 3.10 performance

#179

Post by tambourine_man »

dragonwriter wrote: post #167
tambourine_man wrote: post #138

Earlier quoted context omitted.

Yes, I’m aware of the Smalltalk miracle. Google wasn’t alone in optimizing JS, it actually came late, Safari and Firefox were already competing and improving their runtime speeds, though V8 did doubled down on the bet of a fast JS machine. The question is why there isn’t enough money, given that there obviously is a lot of interest from big players.

> The question is why there isn’t enough money, given that there obviously is a lot of interest from big players. I'd argue that there wasn't actually much interest until recently, and that's because it is only recently that interest in the CPython ecosystem has intersected with interest in speed that has money behind it, because of the sudden broad relevance to commercial business of the Python scientific stack for…

Probably. I’m not a heavy Python user.

A better question would be to ask where Python is slow today and if it matters to big business, then.

It rules in AI, for instance. Is it still mainly glue code for GPU execution and performance isn’t at all critical there?

Re: Python 3.11 vs 3.10 performance

#180

Post by YesThatTom2 »

atwood22 wrote: post #149
pizza234 wrote: post #131

Earlier quoted context omitted.

> Being fast isn't contradictory with this goal. If anything, this is a lesson that so many developers forget. Things should be fast by default. It absolutely is contradictory. If you look at the development of programming languages interpreters/VMs, after a certain point, improvements in speed become a matter of more complex algorithms and data structures. Check out garbage collectors - it's true that Golang keeps a…

Yes, you can spend a large amount of time making things faster. But note that Go's GC is fast, even though it is simple. It's not the fastest, but it is acceptably fast.

Funny you should pick that example in a sub thread that you started with an assertion that code should be fast from by default.

Go’s GC was intentionally slow at first. They wanted to get it right THEN make it fast.

No offense but you’re not making a strong case. You’re sounding like an inexperienced coder that hasn’t yet learned that premature optimization is bad.

Post reply on HN