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 3.11 vs 3.10 performance
41–50 of 460 posts
Re: Python 3.11 vs 3.10 performance
#42Earlier quoted context omitted.
I don't wonder. For me it seems pretty clear. I believe the reason is that python does not need any low-hanging fruits to have people use it, which is why they're a priority for so many other projects out there. Low-hanging fruits attract people who can't reach higher than that. When talking about low-hanging fruits, it's important to consider who they're for. The intended target audience. It's important to ask ones…
> Low-hanging fruits attract people who can't reach higher than that. Do we have completely different definitions of low-hanging fruit? Python not "requiring" speed is a fair enough point if you want to argue against large complex performance-focused initiatives that consume too much of the team's time, but the whole point of calling something "low-hanging fruit" is precisely that they're easy wins — get the performa…
Re: Python 3.11 vs 3.10 performance
#43Earlier 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 is still single-threaded due to the GIL.
Re: Python 3.11 vs 3.10 performance
#44That’s wild, do we typically see such gains in dot releases? I don’t remember the last time this happened. Great news.
As a result, it will be quite some time before we see a version 4.
Re: Python 3.11 vs 3.10 performance
#45These 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
Re: Python 3.11 vs 3.10 performance
#46I 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.
Re: Python 3.11 vs 3.10 performance
#47These 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…
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…
Re: Python 3.11 vs 3.10 performance
#48Earlier quoted context omitted.
I don't wonder. For me it seems pretty clear. I believe the reason is that python does not need any low-hanging fruits to have people use it, which is why they're a priority for so many other projects out there. Low-hanging fruits attract people who can't reach higher than that. When talking about low-hanging fruits, it's important to consider who they're for. The intended target audience. It's important to ask ones…
> Low-hanging fruits attract people who can't reach higher than that. Do we have completely different definitions of low-hanging fruit? Python not "requiring" speed is a fair enough point if you want to argue against large complex performance-focused initiatives that consume too much of the team's time, but the whole point of calling something "low-hanging fruit" is precisely that they're easy wins — get the performa…
Oh, that's not how I interpret low-hanging fruits. From my perspective a "low-hanging fruit" is like cheap pops in wrestling. Things you say of which you know that it will cause a positive reaction, like saying the name of the town you're in.
As far as I know, the low-hanging fruit isn't named like that because of the fruit, but because of those who reach for it.
My reason for this is the fact that the low-hanging fruit is "being used" specifically because there's lots of people who can reach it. The video gaming industry as a whole, but specifically the mobile space, pretty much serves as perfect evidence of that.
Edit:
It's done for a certain target audience, because it increases exposure and interest. In a way, one might even argue that the target audience itself is a low-hanging fruit, because the creators of the product didn't care much about quality and instead went for that which simply impresses.
I don't think python would have gotten anywhere if they had aimed for that kind of low-hanging fruit.
Re: Python 3.11 vs 3.10 performance
#49I 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.
Re: Python 3.11 vs 3.10 performance
#50I 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.
Webassembly can fulfill that requirement for certain use cases
It was designed for "native-like" execution in the browser (or now other runtimes.) It's more like a VM for something like Forth than something like Python.
It's a VM that runs at a much lower level than the ones you'd find inside the interpreter in e.g. Python:
No runtime data model beyond primitive types - nothing beyond simple scalar types; no strings, no collections, no maps. No garbage collection, and in fact just a simple "machine-like" linear memory model
And in fact this is the point of WASM. You can run compiled C programs in the browser or, increasingly, in other places.
Now, are people building stuff like this overtop of WASM? Yes. Are there moves afoot to add GC, etc.? Yes. Personally I'm still getting my feet wet with WebAssembly, so I'm not clear on where these things are at, but I worry that trying to make something like that generic enough to be useful for more than just 1 or 2 target languages could get tricky.
Anyways it feels like we've been here before. It's called the JVM or the .NET CLR.
I like WASM because it's fundamentally more flexible than the above, and there's good momentum behind it. But I'm wary about positioning it as a "generic high level language VM." You can build a high-level language VM on top of it but right now it's more of a target for portable C/C++/Rust programs.