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

151–160 of 460 posts

Re: Python 3.11 vs 3.10 performance

#151

Post by atwood22 »

soperj wrote: post #85
atwood22 wrote: post #79

Earlier quoted context omitted.

> Python was meant as a scrypting language that was easy to learn and work with on all levels. 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.

When you only have so many hours to go around, you concentrate on the main goals.

My point is that you can write fast code just as easily as you can write slow code. So engineers should write fast code when possible. Obviously you can spend a lot of time making things faster, but that doesn't mean you can't be fast by default.

Re: Python 3.11 vs 3.10 performance

#152

Post by 323 »

tasubotadas wrote: post #8

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

It will still improve the data center power bill of thousands of companies, while saying to them "just Rewrite it in Rust" will not.

Re: Python 3.11 vs 3.10 performance

#153

Post by fmakunbound »

AlexTWithBeard wrote: post #133
gpderetta wrote: post #84

Earlier quoted context omitted.

There are a lot of dynamically typed languages that are significantly faster than python. Late binding issues can be effectively worked around.

Do you have an example of a dynamically typed language where, say, addition of two lists of doubles would be significantly faster than in Python?

Probably most Common Lisp implementations.

Re: Python 3.11 vs 3.10 performance

#154

Post by tambourine_man »

323 wrote: post #140
tambourine_man wrote: post #77

Earlier quoted context omitted.

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.

JavaScript doesn't really have C extensions like Python has. PyPy did implement a JIT for Python, and it worked really well, until you tried to use C extensions.

That’s what I meant, if JavaScript hadn’t been trapped in the browser and allowed to call C, maybe there wouldn’t have been so much investment in making it fast.

But still, it’s kind of surprising that PHP has a JIT and Python doesn’t (official implementation I mean, not PyPy).

Re: Python 3.11 vs 3.10 performance

#155

Post by neysofu »

amelius wrote: post #96
atwood22 wrote: post #79

Earlier quoted context omitted.

> Python was meant as a scrypting language that was easy to learn and work with on all levels. 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.

"Premature optimization is the root of all evil." -- Donald Knuth

i would say this quote does not apply here. VM implementations are in the infamous 3% Donald Knuth is warning us about.

Re: Python 3.11 vs 3.10 performance

#156

Post by cglace »

int_19h wrote: post #33
londons_explore wrote: post #5

This looks like incremental performance work rather than a ground-up new approach, like an optimising compiler or JIT...

Python JITs were tried before, more than once. The usual problem there is that the gains are very modest unless you can also break the ABI for native modules. But if you do the latter, most users won't even bother with your version.

I believe a JIT is planned for 3.12

Re: Python 3.11 vs 3.10 performance

#157

Post by gpderetta »

AlexTWithBeard wrote: post #133
gpderetta wrote: post #84

Earlier quoted context omitted.

There are a lot of dynamically typed languages that are significantly faster than python. Late binding issues can be effectively worked around.

Do you have an example of a dynamically typed language where, say, addition of two lists of doubles would be significantly faster than in Python?

You mean concatenating the lists or pairwise addition?

I don't expect the former to be slow in python as it would be a primitive implemented in C (although even a simple lisp interpreter can have an advantage here by just concatenating the conses).

For the latter, any language runtime capable of inference should be able to optimize it.

Re: Python 3.11 vs 3.10 performance

#158

Post by skruger »

AlexTWithBeard wrote: post #133
gpderetta wrote: post #84

Earlier quoted context omitted.

There are a lot of dynamically typed languages that are significantly faster than python. Late binding issues can be effectively worked around.

Do you have an example of a dynamically typed language where, say, addition of two lists of doubles would be significantly faster than in Python?

Racket

Re: Python 3.11 vs 3.10 performance

#159

Post by Starlevel001 »

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 called the JVM and everyone has spent the last twenty years getting really upset about it.

Re: Python 3.11 vs 3.10 performance

#160

Post by luhn »

dagmx wrote: post #30
imwillofficial wrote: post #7

That’s wild, do we typically see such gains in dot releases? I don’t remember the last time this happened. Great news.

Programming language dot releases can tend to be significant. Semver often means that major is the language version, and minor is the runtime version

To nitpick a little bit, Python does not follow semver and does not claim to follow semver. Minor versions are mostly backwards compatible, but do include breaking changes.
Post reply on HN