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

111–120 of 460 posts

Re: Python 3.11 vs 3.10 performance

#111

Post by Sesse__ »

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…

Because Guido van Rossum just isn't very good with performance, and when others tried to contribute improvements, he started heckling their talk because he thought they were “condescending”: https://lwn.net/Articles/754163/ And by this time, we've come to the point where the Python extension API is as good as set in stone.

Note that all of the given benchmarks are microbenchmarks; the gains in 3.11 are _much_ less pronounced on larger systems like web frameworks.

Re: Python 3.11 vs 3.10 performance

#112

Post by dekhn »

switch007 wrote: post #75
dekhn wrote: post #37

Earlier quoted context omitted.

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

Was the project run by a team based in Africa or Europe?

I don't know! [Whoosh]

Re: Python 3.11 vs 3.10 performance

#114

Post by _the_inflator »

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 in which regard? Fast coding? Fast results after hitting "run"? ;)

Re: Python 3.11 vs 3.10 performance

#115

Post by dragonwriter »

maxbond wrote: post #109
amelius wrote: post #96

Earlier quoted context omitted.

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

Python was meeting needs well enough to be one of, if not the single, most popular language for a considerable time and continuing to expand and become dominant in new application domains while languages that focussed more heavily on performance rose and fell.

And it's got commercial interests willing to throw money at performance now because of that.

Seems like the Python community, whether as top-down strategy or emergent aggregate of grassroots decisions made the right choices here.

Re: Python 3.11 vs 3.10 performance

#116

Post by liuliu »

FartyMcFarter wrote: post #58
missblit wrote: post #18

Earlier quoted context omitted.

So we have: * Statically allocated ("frozen") core modules for fast imports * Avoid memory allocation for frames / faster frame creation * Inlined python functions are called in pure python without needing to jump through C * Optimizations that take advantage of speculative typing (Reminds me of Javascript JIT compilers -- though according to the FAQ Python isn't JIT yet) * Smaller memory usage for frames, objects, a…

> Inlined python functions are called in pure python without needing to jump through C Given that Python is interpreted, it's quite unclear what this could mean. Also, what does it mean to "call" an inlined function?? Isn't the point of inline functions that they don't get called at all?

It seems to be just previously, it does:

  switch (op) {
    case "call_function":
      interpret(op.function)
    ...
  }
Now it does:

  switch (op) {
    case "call_function":
      ... setup frame objects etc ...
      pc = op.function
      continue
    ....
  }
Not sure if they just "inlined" it or use tail-call elimination trick.

Re: Python 3.11 vs 3.10 performance

#117

Post by cmrdporcupine »

dragonwriter wrote: post #60
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.

There have been many attempts to do this, but the problem seems to be that a good target for one scripting language isn't necessarily a good target for another one with a different model, and the interest in a common backend isn't strong enough to overcome that. (Though JS had some potential to do that by the power of it's browser role, before compiling interpreters to WASM became a better way of getting browser supp…

Arguably the JVM has been the most successful variant of this type of thing. It's not a bad generic higher level language target overall.

It's just it also has sooo much historical baggage and normative lifestyle assumptions along with it, and now it's passed out of favour.

And historically support in the browser was crap and done at the wrong level ("applets") and then that became a dead end and was dropped.

Re: Python 3.11 vs 3.10 performance

#118

Post by dragonwriter »

latenightcoding wrote: post #107
dragonwriter wrote: post #67

Earlier quoted context omitted.

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

Yes, the quote from the Parrot website I provided says exactly that: the role Parrot intended to fill for Perl6 has been filled by MoarVM supporting the Rakudo compiler.

Re: Python 3.11 vs 3.10 performance

#119

Post by IceHegel »

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 there a reason python hasn't already done this?

Re: Python 3.11 vs 3.10 performance

#120

Post by [deleted] »

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]
Post reply on HN