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

131–140 of 460 posts

Re: Python 3.11 vs 3.10 performance

#131

Post by pizza234 »

atwood22 wrote: post #79
gostsamo wrote: post #68

Earlier quoted context omitted.

A few people tried to excuse the slow python, but as far as I know the story, excuses are not necessary. Truth is that python was not meant to be fast, its source code was not meant to be fast, and its design was not optimized with the idea of being fast. Python was meant as a scrypting language that was easy to learn and work with on all levels and the issue of its slowness became important when it outgrew its role…

> 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.

> 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 simple one, but other languages progressively increase its sophistication - think about Java or Ruby.

Or JITs, for example, which are the latest and greatest in terms of programming languages optimization; they are complicated beasts.

Re: Python 3.11 vs 3.10 performance

#132

Post by chaosfox »

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

python isn't premature. python is more than 30 years old now, python 3 was released more than 10 years go.

Re: Python 3.11 vs 3.10 performance

#133

Post by AlexTWithBeard »

gpderetta wrote: post #84
AlexTWithBeard wrote: post #64

Earlier quoted context omitted.

One of the biggest contributors in Python's (lack of) speed is dynamic typing. While a jump is a jump and an assignment is an assignment, an addition is more like "hmm... what is a left operand... is it double? what is a right operand? wow, it's also a double! okay, cpu add eax, ebx".

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?

Re: Python 3.11 vs 3.10 performance

#134

Post by dragonwriter »

coldtea wrote: post #126
dragonwriter wrote: post #97

Earlier quoted context omitted.

Those people were not being paid to speed up CPython, though, but mostly-source-compatible (but not at all native extension compatible) alternative interpreters.

That's because the core team wasn't friendly to them making changes in CPython. Not because they deliberately only wanted to build an alternative interpreter.

That's absolutely not the case with IronPython, where being tied to the .NET ecosystem was very much the point.

But if it was just core-team resistance and not a more fundamentally different objective than just improving the core interpreter performance, maintaining support for native extensions while speeding up the implementation would have been a goal even if it had to be in a fork.

They were solving a fundamentally different (and less valuable to the community) problem than the new faster CPython project.

Re: Python 3.11 vs 3.10 performance

#135

Post by ikinsey »

1337shadow wrote: post #92
ikinsey wrote: post #69

Earlier quoted context omitted.

I love asyncio! It's a very well put together library. It provides great interfaces to manage event loops, io, and some basic networking. It gives you a lot of freedom to design asynchronous systems as you see fit. However, batteries are not included. For example, it provides no HTTP client/server. It doesn't interop with any synchronous IO tools in the standard library either, making asyncio a very insular environme…

It depends how you see it https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...

This is exactly why Go is a better option for async use cases.

Re: Python 3.11 vs 3.10 performance

#136

Post by zitterbewegung »

gostsamo wrote: post #94
zitterbewegung wrote: post #86

Earlier quoted context omitted.

Meta has an active port to optimize instagram to make it faster and they just open sourced it to have optimizations merged back into CPython When you have so many large companies with a vested interest in optimization I believe that Python can become faster by doing realistic and targeted optimizations . The other strategies to optimize didn’t work at all or just served internal problems at large companies .

O, I agree. As I said, when python and its uses scaled, it became quite necessary to make it fast. I like that it will be fast as well and I am not happy that it is slow at the moment. My point is that there are reasons why it was not optimized in the beginning and why this process of optimizations has started now.

Back when Python was started there was really C or C++ for optimized programs and scripting languages like Python and Perl. But since Python had the ability for C Extensions it allowed it to bypass those problems. Since Python was easy to learn both web developers and scientists to learn. Then financial organizations started to get interested and that’s really how Python cemented itself.

What exactly do you do with Python that slows you down ?

Re: Python 3.11 vs 3.10 performance

#137

Post by pdpi »

MrYellowP wrote: post #48
pdpi wrote: post #29

Earlier quoted context omitted.

> Low-hanging fruits attract people who can't reach higher than that. Do we have completely different definitions of low-hanging fruit? Python not "requiring" speed is a fair enough point if you want to argue against large complex performance-focused initiatives that consume too much of the team's time, but the whole point of calling something "low-hanging fruit" is precisely that they're easy wins — get the performa…

> is precisely that they're easy wins — get the performance without a large effort commitment. Oh, that's not how I interpret low-hanging fruits. From my perspective a "low-hanging fruit" is like cheap pops in wrestling. Things you say of which you know that it will cause a positive reaction, like saying the name of the town you're in. As far as I know, the low-hanging fruit isn't named like that because of the fruit…

Ah, ok. We're looking at the same thing from different perspectives then.

What I'm describing, which is the sense I've always seen that expression used as in engineering, and what GP was describing, is: this is an easy low-risk project that have a good chance of producing results.

E.g. If you tell me that your CRUD application suffers from slow reads, the low-hanging fruit is stuff like making sure your queries are hitting appropriate indices instead of doing full table scans, or checking that you're pooling connections instead of creating/dropping connections for every individual query. Those are easy problems to check for and act on that don't require you to try to grab the fruit hard-to-reach fruit at the top of the tree like completely redesigning or DB schema or moving to a new DB engine altogether.

Re: Python 3.11 vs 3.10 performance

#138

Post by tambourine_man »

dragonwriter wrote: post #89
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 has proven that any language can be made fast given enough money and brains, Yeah but commercial Smalltalk proved that a long time before JS did. (Heck, back when it was maintained, the fastest Ruby implementation was built on top of a commercial Smalltalk system, which makes sense given they have a reasonably similar model.) The hard part is that “enough money“ is...not a given, especially for noncommer…

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.

Re: Python 3.11 vs 3.10 performance

#139

Post by dekhn »

dragonwriter wrote: post #134
coldtea wrote: post #126

Earlier quoted context omitted.

That's because the core team wasn't friendly to them making changes in CPython. Not because they deliberately only wanted to build an alternative interpreter.

That's absolutely not the case with IronPython, where being tied to the .NET ecosystem was very much the point. But if it was just core-team resistance and not a more fundamentally different objective than just improving the core interpreter performance, maintaining support for native extensions while speeding up the implementation would have been a goal even if it had to be in a fork. They were solving a fundamental…

If I remember correctly iron python ran on mono it just didn't have all of the .net bits. I remember at the python conference when it was introduced he actually showed how you could bring up clippy or a wizard programmatically from python talking directly to the operating system through its native apis.

Really the value came from the thread safe container/collections data types which are the foundation of high performance programming

Re: Python 3.11 vs 3.10 performance

#140

Post by 323 »

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.

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.

Post reply on HN