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

141–150 of 460 posts

Re: Python 3.11 vs 3.10 performance

#141

Post by outworlder »

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?

> Given that Python is interpreted, it's quite unclear what this could mean.

Python is compiled. CPython runs bytecode.

(If Python is interpreted, then so is Java without the JIT).

Re: Python 3.11 vs 3.10 performance

#143

Post by ihaveajob »

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…

Indeed, and that's why I love it. When I need extra performance, which is very rarely, I don't mind spending extra effort outsourcing it to a binary module. More often, the problem is an inefficient algorithm or data arrangement.

I took a graduate level data structures class and the professor used Python among other things "because it's about 80 times slower than C, so you have to think hard about your algorithms". At scale, that matters.

Re: Python 3.11 vs 3.10 performance

#144

Post by BugsJustFindMe »

coldtea wrote: post #128
BugsJustFindMe wrote: post #22

Earlier quoted context omitted.

I find asyncio to be horrendous, both because of the silliness of its demands on how you build your code and also because of its arbitrarily limited scope. Thread/ProcessPoolExecutor is personally much nicer to use and universally applicable...unless you need to accommodate Ctrl-C and then it's ugly again. But fixing _that_ stupid problem would have been a better expenditure of effort than asyncio.

> I find asyncio to be horrendous, both because of the silliness of its demands on how you build your code and also because of its arbitrarily limited scope. Do you compare it to threads and pools, or judge it on its merits as an async framework (with you having experience of those that you think are done better elsewhere, e.g. in Javascript, C#, etc)? Because both things you mention "demands on how you build your co…

> Because both things you mention "demands on how you build your code" and "limited scope" are part of the course with async in most languages

I don't see how "asyncio is annoying and can only be used for a fraction of scenarios everywhere else too, not just here" is anything other than reinforcement of what I said. OS threads and processes already exist, can already be applied universally for everything, and the pool executors can work with existing serial code without needing the underlying code to contort itself in very fundamental ways.

Python's version of asyncio being no worse than someone else's version of asyncio does not sound like a strong case for using Python's asyncio vs fixing the better-in-basically-every-way concurrent futures interface that already existed.

Re: Python 3.11 vs 3.10 performance

#145

Post by [deleted] »

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.

[deleted]

Re: Python 3.11 vs 3.10 performance

#146

Post by fmakunbound »

tasubotadas wrote: post #8

Cool improvement but changes very little when Python is x100 times slower than other GC languages.

This was my immediate thought when I looked at the numbers, but I didn't want to be "that guy". I think if all you ever work in is Python, it's still nice even if it is a tiny improvement.

Re: Python 3.11 vs 3.10 performance

#147

Post by BeetleB »

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.

> Things should be fast by default.

In over 90% of my work in the SW industry, being fast(er) was of no benefit to anyone.

So no, it should not be fast by default.

Re: Python 3.11 vs 3.10 performance

#148

Post by bobbylarrybobby »

AlexTWithBeard wrote: post #133
gpderetta wrote: post #84

Earlier quoted context omitted.

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?

Doesn't that sort of operation become very fast in JS after a few runs?

Re: Python 3.11 vs 3.10 performance

#149

Post by atwood22 »

pizza234 wrote: post #131
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.

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

Yes, you can spend a large amount of time making things faster. But note that Go's GC is fast, even though it is simple. It's not the fastest, but it is acceptably fast.

Re: Python 3.11 vs 3.10 performance

#150

Post by pca006132 »

dekhn wrote: post #121
Jasper_ wrote: post #61

Earlier quoted context omitted.

> 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 Yo…

Yup. Sad but true. I just wanted c++ style multithreading with unsafe shared memory but it's too late. I was impressed by the recent fork that addresses this in a very sophisticated way, but realistically gil cpython will keep finding speed ups to stave off the transition.

wondering how that interacts with c/c++ extensions that presumes the existance of the GIL
Post reply on HN