Python 3.11 vs 3.10 performance • Hacker News Board

Re: Python 3.11 vs 3.10 performance

#61

Post by Jasper_ » Wed, Jul 06, 2022, 3:48 PM UTC

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

Because the core team just hasn't prioritized performance, and have actively resisted performance work, at least until now. The big reason has been about maintainership cost of such work, but often times plenty of VM engineers show up to assist the core team and they have always been pushed away.

> Now let's get a sane concurrency story

You really can't easily add a threading model like that and make everything go faster. The hype of "GIL-removal" branches is that you can take your existing threading.Thread Python code, and run it on a GIL-less Python, and you'll instantly get a 5x speedup. In practice, that's not going to happen, you're going to have to modify your code substantially to support that level of work.

The difficulty with Python's concurrency is that the language doesn't have a cohesive threading model, and many programs are simply held alive and working by the GIL.

Re: Python 3.11 vs 3.10 performance

#62

Post by mgaunard » Wed, Jul 06, 2022, 3:49 PM UTC

Alex3917 wrote: post #21

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…

> Of course one wonders why they haven't been a low-hanging fruit over the past 25 years. Because it's developed and maintained by volunteers, and there aren't enough folks who want to spend their volunteer time messing around with assembly language. Nor are there enough volunteers that it's practical to require very advanced knowledge of programming language design theory and compiler design theory as a prerequisite…

first, there are lots of volunteers that want to mess with assembly language.

second, CPython is just a C interpeter, there isn't much assembly if any.

third, contributing to CPython is sufficiently high-profile you could easily land a 500k-job just by putting it on your CV.

No, those are not the real reasons why it hasn't happened before.

Re: Python 3.11 vs 3.10 performance

#63

Post by pstrateman » Wed, Jul 06, 2022, 3:49 PM UTC

dekhn wrote: post #37

KptMarchewa wrote: post #17

Earlier quoted context omitted.

Answer is very simple. Amount of people who got paid to make python fast was rounded to 0.

Not really. There were a couple engineers working at Google on a project called unladen swallow which was extremely promising but it eventually got canceled. The developer who worked at Microsoft to make iron python I think that was his full-time project as well and it was definitely faster than cpython at the time

Neither of those projects were ever going to be accepted upstream though.

Re: Python 3.11 vs 3.10 performance

#64

Post by AlexTWithBeard » Wed, Jul 06, 2022, 3:50 PM UTC

speedgoose wrote: post #28

woodruffw wrote: post #16

Earlier quoted context omitted.

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

Python being interpreted is the main reason why it’s slow, but not the excuse to not compare it to similar and faster programming languages.

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

Re: Python 3.11 vs 3.10 performance

#65

Post by staticassertion » Wed, Jul 06, 2022, 3:50 PM UTC

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…

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

Re: Python 3.11 vs 3.10 performance

#66

Post by Fiahil » Wed, Jul 06, 2022, 3:51 PM UTC

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…

> Now let's get a sane concurrency story (no multiprocessing / queue / pickle hacks) and suddenly it's a completely different language!

Yes, and I would argue it already exists and is called Rust :)

Semi-jokes aside, this is difficult and is not just about removing the GIL and enabling multithreading ; we would need to get better memory and garbage collection controls. Parts of what's make python slow and dangerous in concurrent settings are the ballooning memory allocations on large and fragmented workloads. A -Xmx would help.

Re: Python 3.11 vs 3.10 performance

#67

Post by dragonwriter » Wed, Jul 06, 2022, 3:51 PM UTC

roelschroeven wrote: post #56

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?

Parrot [0] was meant to be that and the main VM for Perl6 (now Raku) and failed at both.

[0] http://www.parrot.org/ states:

The Parrot VM is no longer being actively developed.

Last commit: 2017-10-02

The role of Parrot as VM for Perl 6 (now "Raku") has been filled by MoarVM, supporting the Rakudo compiler.

[...]

Parrot, as potential VM for other dynamic languages, never supplanted the existing VMs of those languages.

Re: Python 3.11 vs 3.10 performance

#68

Post by gostsamo » Wed, Jul 06, 2022, 3:52 PM UTC

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…

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 and became an application language powering large parts of the internet and the bigger part of the very expensive ML industry. I know that speed is a virtue, but it becomes a fundamental virtue when you have to scale and python was not meant to scale. So, yes, it is easy for people to be righteous and furious over the issue, but being righteous in hindsight is much easier than useful.

Re: Python 3.11 vs 3.10 performance

#69

Post by ikinsey » Wed, Jul 06, 2022, 3:52 PM UTC

siekmanj wrote: post #6

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…

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

For the majority of problems, Go or Node.js may be better options. They have much more mature environments for managing asynchrony.

Re: Python 3.11 vs 3.10 performance

#70

Post by Angostura » Wed, Jul 06, 2022, 3:52 PM UTC

mgaunard wrote: post #62

Alex3917 wrote: post #21

Earlier quoted context omitted.

> Of course one wonders why they haven't been a low-hanging fruit over the past 25 years. Because it's developed and maintained by volunteers, and there aren't enough folks who want to spend their volunteer time messing around with assembly language. Nor are there enough volunteers that it's practical to require very advanced knowledge of programming language design theory and compiler design theory as a prerequisite…

first, there are lots of volunteers that want to mess with assembly language. second, CPython is just a C interpeter, there isn't much assembly if any. third, contributing to CPython is sufficiently high-profile you could easily land a 500k-job just by putting it on your CV. No, those are not the real reasons why it hasn't happened before.

Go on then - what are the real reasons, in your mind?