Python 3.11 vs 3.10 performance • Hacker News Board

Re: Python 3.11 vs 3.10 performance

#101

Post by pydry » Wed, Jul 06, 2022, 4:15 PM UTC

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.

Fast typically comes with trade offs.

Languages that tried to be all things to all people really havent done so well.

Re: Python 3.11 vs 3.10 performance

#102

Post by GrayShade » Wed, Jul 06, 2022, 4:15 PM UTC

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

You should probably read the full context around that quote, I'm sick and tired of everyone repeating it mindlessly:

https://softwareengineering.stackexchange.com/a/80092

> Yet we should not pass up our opportunities in that critical 3%. A good programmer will not be lulled into complacency by such reasoning, he will be wise to look carefully at the critical code; but only after that code has been identified.

Re: Python 3.11 vs 3.10 performance

#103

Post by hn_saver » Wed, Jul 06, 2022, 4:16 PM UTC

sgtlaggy wrote: post #38

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

Concurrency in Python is a weird topic, since multiprocessing is the only "real" concurrency. Threading is "implicit" context switching all in the same process/thread, asyncio is "explicit" context switching. On top of that, you also have the complication of the GIL. If threads don't release the GIL, then you can't effectively switch contexts.

Threading IS concurrency. When you say "real" concurrency, you actually mean parallelism.

Re: Python 3.11 vs 3.10 performance

#104

Post by alexfromapex » Wed, Jul 06, 2022, 4:17 PM UTC

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.

Will be in the 3.11 release: https://docs.python.org/3.11/whatsnew/3.11.html#new-features

Re: Python 3.11 vs 3.10 performance

#105

Post by [deleted] » Wed, Jul 06, 2022, 4:18 PM UTC

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

[deleted]

Re: Python 3.11 vs 3.10 performance

#106

Post by tasubotadas » Wed, Jul 06, 2022, 4:18 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.

>Python being interpreted is the main reason why it’s slow

Common Lisp and Java begs to disagree.

Re: Python 3.11 vs 3.10 performance

#107

Post by latenightcoding » Wed, Jul 06, 2022, 4:19 PM UTC

dragonwriter wrote: post #67

roelschroeven wrote: post #56

Earlier quoted context omitted.

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…

Raku uses MoarVM

Re: Python 3.11 vs 3.10 performance

#108

Post by winstonewert » Wed, Jul 06, 2022, 4:19 PM UTC

GrayShade wrote: post #102

amelius wrote: post #96

Earlier quoted context omitted.

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

You should probably read the full context around that quote, I'm sick and tired of everyone repeating it mindlessly: https://softwareengineering.stackexchange.com/a/80092 > Yet we should not pass up our opportunities in that critical 3%. A good programmer will not be lulled into complacency by such reasoning, he will be wise to look carefully at the critical code; but only after that code has been identified.

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

Re: Python 3.11 vs 3.10 performance

#109

Post by maxbond » Wed, Jul 06, 2022, 4:21 PM UTC

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

This certainly does not mean, "tolerate absurd levels of technical debt, and only ever think about performance in retrospect."

Re: Python 3.11 vs 3.10 performance

#110

Post by ketralnis » Wed, Jul 06, 2022, 4:21 PM UTC

simias wrote: post #52

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…

I suspect that the amount of people and especially companies willing to spend time and money optimizing Python are fairly low. Think about it: if you have some Python application that's having performance issues you can either dig into a foreign codebase to see if you can find something to optimize (with no guarantee of result) and if you do get something done you'll have to get the patch upstream. And all that "only…

> you can either dig into a foreign codebase ... > Or you could rewrite your application

Programmers love to save an hour in the library by spending a week in the lab