What happened to multithreaded Facebookthon?
Python 3.11 vs 3.10 performance
91–100 of 460 posts
Re: Python 3.11 vs 3.10 performance
#92Earlier 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
I love asyncio! It's a very well put together library. It provides great interfaces to manage event loops, io, and some basic networking. It gives you a lot of freedom to design asynchronous systems as you see fit. However, batteries are not included. For example, it provides no HTTP client/server. It doesn't interop with any synchronous IO tools in the standard library either, making asyncio a very insular environme…
It depends how you see it https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...
Re: Python 3.11 vs 3.10 performance
#93I’d be curious to see the speed up compared to python 2.4. To see how far it’s come since I first got started with it.
it means you are not following PEP8 if you get non descriptive errors, it means you haven't followed proper exception handling/management its not the fault of Python but the developer. go ahead and downvote me but you if you mentioned parent's comment in an interview, you would not receive a call back or at least I hope the interviewer is realizing the skill gap.
How so?
Re: Python 3.11 vs 3.10 performance
#94Earlier 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…
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 .
O, I agree. As I said, when python and its uses scaled, it became quite necessary to make it fast. I like that it will be fast as well and I am not happy that it is slow at the moment. My point is that there are reasons why it was not optimized in the beginning and why this process of optimizations has started now.
Re: Python 3.11 vs 3.10 performance
#95These 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…
Guido stepping away from the language will have a lot of impact on changes that were culturally guided.
Guido is one of the people leading the current performance efforts.
Re: Python 3.11 vs 3.10 performance
#96Earlier 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.
"Premature optimization is the root of all evil."
-- Donald Knuth
Re: Python 3.11 vs 3.10 performance
#97Earlier quoted context omitted.
Answer is very simple. Amount of people who got paid to make python fast was rounded to 0.
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
Those people were not being paid to speed up CPython, though, but mostly-source-compatible (but not at all native extension compatible) alternative interpreters.
Re: Python 3.11 vs 3.10 performance
#98These 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 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…
> 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.
Ah! So they are so tall that picking the low-hanging fruit would be too inconvenient for them.
Talk about stretching an analogy too far.
Re: Python 3.11 vs 3.10 performance
#99Earlier 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.
> Concurrency in Python is a weird topic, since multiprocessing is the only "real" concurrency.
You are confusing concurrency and parallelism.
> Threading is "implicit" context switching all in the same process/thread
No, threading is separate native threads but with a lock that prevents execution of Python code in separate threads simultaneously (native code in separate threads, with at most on running Python, can still work.)
Re: Python 3.11 vs 3.10 performance
#100Earlier 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.)
> 25% faster is still 25% faster, even if the code would have been 100x faster to begin with in another language.) And that's even assuming that the code would have existed at all in another language. The thing about interpreted GC languages is that the iterative loop of creation is much more agile, easier to start with and easier to prototype in than a compiled, strictly typed language.
I think this is the best explanation for its popularity. Sure, it runs slow, but it's very fast to write. The latter is usually more important in the world of business, for better or worse.