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

81–90 of 460 posts

Re: Python 3.11 vs 3.10 performance

#81

Post by Joker_vD »

dekhn wrote: post #40
siekmanj wrote: post #6

Earlier quoted context omitted.

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

Asyncio violates every aspect of compositional orthogonality just like decorators you can't combine it with anything else without completely rewriting your code around its constrictions. It's also caused a huge amount of pip installation problems around the AWS CLI and boto

Having both Task and Future was a pretty strange move; and the lack of static typing certainly doesn't help: the moment you get a Task wrapping another Task wrapping the actual result, you really want some static analysis tool to tell you that you forgot one "await".

Re: Python 3.11 vs 3.10 performance

#82

Post by ianbicking »

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

Python is compiled to a VM (that is CPython). The semantics and implementation of the VM haven't prioritized performance as much as some other systems. Here we're seeing improvements in the implementation. But the semantics will be the hard part, as those semantics limit the performance. For instance "a + b" is (I believe) compiled into bytecodes that pretty much follow the expression. But the implementation of "add" has to take into account __add__() and the possible function calls and exceptions and return types that implies. If you compiled that all down to machine code (which people have done) you'd still have to run all that code to check types and the existence of methods and so on.

Re: Python 3.11 vs 3.10 performance

#83

Post by [deleted] »

AlexTWithBeard wrote: post #64
speedgoose wrote: post #28

Earlier quoted context omitted.

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

[deleted]

Re: Python 3.11 vs 3.10 performance

#84

Post by gpderetta »

AlexTWithBeard wrote: post #64
speedgoose wrote: post #28

Earlier quoted context omitted.

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

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

Re: Python 3.11 vs 3.10 performance

#85

Post by soperj »

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.

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

Re: Python 3.11 vs 3.10 performance

#86

Post by zitterbewegung »

gostsamo wrote: post #68
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…

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 .

Re: Python 3.11 vs 3.10 performance

#87

Post by AndrewOMartin »

staticassertion wrote: post #76
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…

> Because it's developed and maintained by volunteers Who is working on python voluntarily? I would assume that, like the Linux kernel, the main contributors are highly paid. Certainly, having worked at Dropbox, I can attest to at least some of them being highly paid.

Raymond Hettinger gets his Python Contributor salary doubled ever couple of years.

Re: Python 3.11 vs 3.10 performance

#88

Post by staticassertion »

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.

https://github.com/mypyc/mypyc

> Mypyc compiles Python modules to C extensions. It uses standard Python type hints to generate fast code. Mypyc uses mypy to perform type checking and type inference.

Re: Python 3.11 vs 3.10 performance

#89

Post by dragonwriter »

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 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 noncommercial projects. JS got it because Google decided JavaScript speed was integral to it's business of getting the web to replace local apps. Microsoft recently developed sufficient interest in Python to throw some money at it.

Re: Python 3.11 vs 3.10 performance

#90

Post by staticassertion »

AlexTWithBeard wrote: post #64
speedgoose wrote: post #28

Earlier quoted context omitted.

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

Also "what is equals?". That's why people will do:

    def fooer(i: str, strings: list[str]):
        push = str.append
        for s in strings:
            push(i, s)
Apparently this helps the interpreter understand that `append` is not getting overwritten in the global scope elsewhere.
Post reply on HN