A viable solution for Python concurrency • Hacker News Board

Re: A viable solution for Python concurrency

#231

Post by SoylentOrange » Sat, Oct 16, 2021, 2:16 AM UTC

cletus wrote: post #226

This feels like Schrodinger's Cake to me (you know, having it and eating it too). > ... the first of which is called "biased reference counts" ... With this scheme, the reference count in each object is split in two, with one "local" count for the owner (creator) of the object and a shared count for all other threads. Since the owner has exclusive access to its count, increments and decrements can be done with fast,…

> My personal view is that the world has largely moved on from dynamically typed languages for anything non-trivial or that isn't essentially plumbing. For good reason. Of course people will bring up Javascript but it has a captive market as being the only thing that'll universally run code in a browser and the likes of TypeScript can ease that burden anyway.

This is not correct. There is a lot of data analysis code in the research and scientific community written in python. A lot of PyCon attendees and speakers come from these communities. Oftentimes, it’s not easy to write code to perform a task entirely in numpy, and then you incur massive slowdowns (often 20-100x). This is a common and contemporary problem in the python ecosystem.

GVR initially didn’t think that python needed to be faster either, but recently changed his mind. You can find a presentation on his motivations here: https://github.com/faster-cpython/ideas/blob/main/FasterCPyt...

Sam Gross comes out of that community so he’s familiar with the motivations for making raw python faster.

Re: A viable solution for Python concurrency

#232

Post by pansa2 » Sat, Oct 16, 2021, 2:25 AM UTC

cletus wrote: post #226

This feels like Schrodinger's Cake to me (you know, having it and eating it too). > ... the first of which is called "biased reference counts" ... With this scheme, the reference count in each object is split in two, with one "local" count for the owner (creator) of the object and a shared count for all other threads. Since the owner has exclusive access to its count, increments and decrements can be done with fast,…

> So if the owner needs to check the shared ref count every time it changes the count of the non-atomic local count, isn't that basically all the negatives of a single shared atomic counter?

I think the owner only needs to check the shared count when it changes the local count to zero, not every time it changes the local count.

Re: A viable solution for Python concurrency

#233

Post by justusw » Sat, Oct 16, 2021, 2:34 AM UTC

BiteCode_dev wrote: post #76

nine_k wrote: post #41

Earlier quoted context omitted.

BTW I wonder why async is so painless in ES6 compared to Python. Why the presence of GIL (which JS also has) did not make running async coroutines completely transparent, as it made running generators (which are, well, coroutines already). Why the whole even loop thing is even visible at all.

I used them both extensively, and here are the main reasons I can think of: - The event loop in JS is invisible and implicit. V8 proved it can be done without paying a cost for it, and in fact most real life python projects are using uvloop because it's faster than asyncio default loop. JS dev don't think of the loop at all, because it's always been there. They don't have to chose a loop, or thinking about its lifecy…

I’m not an expert on Node.js but I was always under the impression that you couldn’t write await outside of an async function. Has that changed recently?

Re: A viable solution for Python concurrency

#234

Post by OOPMan » Sat, Oct 16, 2021, 2:36 AM UTC

It's weird how the more I work with Python, the less I want to work with Python.

I moved into the language full-time in 2010 and it's now 2021.

The packaging ecosystem is still a burning dumpster fire, the performance is still hot garbage and the whole approach to asyncio makes me want to bang my head against a wall.

Tthe latest additions in Python 3.10 have me shaking my head. I love pattern matching (Yes, Scala fanboy detected) but shoving them into Python just seems....poorly thought out.

I really hope to move away from the language in the long-term because I feel like it's a bad thing when I would rather work in Java or C++ than Python. For me it feels like Java and C++ took a look at themselves at the end of the 2000s and said "Okay, we need to sort something out, what we're doing now is not winning any hearts" while Python did also did some introspection and decided "Meh, let's just keep throwing mud at the wall until something sticks". It's one of the few languages I've worked with which seems to be actively getting worse every year, which is kinda sad :-/

Re: A viable solution for Python concurrency

#235

Post by rmdashrfstar » Sat, Oct 16, 2021, 2:43 AM UTC

OOPMan wrote: post #234

It's weird how the more I work with Python, the less I want to work with Python. I moved into the language full-time in 2010 and it's now 2021. The packaging ecosystem is still a burning dumpster fire, the performance is still hot garbage and the whole approach to asyncio makes me want to bang my head against a wall. Tthe latest additions in Python 3.10 have me shaking my head. I love pattern matching (Yes, Scala fan…

You’ll find camaraderie in the Rust community, we have similar stories… :)

One of us, one of us, one of us!

Re: A viable solution for Python concurrency

#236

Post by OOPMan » Sat, Oct 16, 2021, 2:44 AM UTC

rmdashrfstar wrote: post #235

OOPMan wrote: post #234

It's weird how the more I work with Python, the less I want to work with Python. I moved into the language full-time in 2010 and it's now 2021. The packaging ecosystem is still a burning dumpster fire, the performance is still hot garbage and the whole approach to asyncio makes me want to bang my head against a wall. Tthe latest additions in Python 3.10 have me shaking my head. I love pattern matching (Yes, Scala fan…

You’ll find camaraderie in the Rust community, we have similar stories… :) One of us, one of us, one of us!

Rust is on my list of things to look at one day, but I'm still on the Scala train for now ;-)

Re: A viable solution for Python concurrency

#237

Post by frenchy » Sat, Oct 16, 2021, 2:50 AM UTC

pansa2 wrote: post #198

huetius wrote: post #171

Many of the additions to Python in the past decade have been very impressive, but am I wrong in thinking that they suffer from a kind of diminishing marginal benefit? If I am building a project where concurrency or asynchrony are essential, am I going to choose Python? If I need to bolt these on to an existing project to meet a deadline, how much runway do I really get from these enhancements before I hit the limitat…

> am I going to choose Python? IMO most of the additions to Python in the past decade haven’t been aimed at people choosing a language, but at people working on large existing Python codebases who have too much inertia to change languages. The cause of this is that the people in charge of language design (first Guido at Dropbox and now members of the Steering Council) are in exactly that situation. The effect is that…

People have been using Python for way beyond what it was "originally good for" as long as I've been a programmer (close to 20 years).

For some reason people seem to think that since Python code is easy to read, that it's a "scripting language" (whatever that means). There are a lot of use cases for a language that's easy to do easy things in, and where performance doesn't really matter (or can be sorted out later.

Re: A viable solution for Python concurrency

#238

Post by kumarvvr » Sat, Oct 16, 2021, 2:50 AM UTC

rmdashrfstar wrote: post #235

OOPMan wrote: post #234

It's weird how the more I work with Python, the less I want to work with Python. I moved into the language full-time in 2010 and it's now 2021. The packaging ecosystem is still a burning dumpster fire, the performance is still hot garbage and the whole approach to asyncio makes me want to bang my head against a wall. Tthe latest additions in Python 3.10 have me shaking my head. I love pattern matching (Yes, Scala fan…

You’ll find camaraderie in the Rust community, we have similar stories… :) One of us, one of us, one of us!

For those who were brought up on C#, Java and Python (me), having minimal experience with C & C++, Rust seems too complex and the syntax too finicky.

I guess years of Python has spoiled me.

Re: A viable solution for Python concurrency

#239

Post by rmbyrro » Sat, Oct 16, 2021, 2:52 AM UTC

SoylentOrange wrote: post #229

mmastrac wrote: post #225

Python3 would have been a great time to _also_ break the C interface in a way that would make multi-threading easier. An opt-in for C libraries that are multi-threaded-aware could be useful as well. It would be a forcing function to ensure that libraries _eventually_ become MT-aware and eventually the older versions would drop away.

Python 3.0 was released in 2008, over 13 years ago. We are almost certainly much closer to python 4.0 than to 3.0 today (given 3.10 RC is currently live)

Current version being 3.10 doesn't make it any closer to 4. It can go to 3.99. And they actually started talking about being able to go even further beyond that before a 4.0.

Re: A viable solution for Python concurrency

#240

Post by ameixaseca » Sat, Oct 16, 2021, 2:53 AM UTC

twic wrote: post #120

ameixaseca wrote: post #107

Earlier quoted context omitted.

I couldn't find this in the design document but the only obvious solution is to track globals via the shared count. Since a global reference is part of all threads simultaneously, it cannot be treated as local. If you follow this reasoning, the operations above result in local=0/shared=0 after the last assignment.

As i said in the comment, that doesn't work. Put a list in the global, and then push and pop the string on the list. Even better, push the string into a local list, then put that list in another local list, then put that in a global, etc. You would need to dynamically keep every object reachable from a global marked as such, and that's a non-starter.

Sorry, you're right - I missed that part. I had a few assumptions in mind that obviously break down with a bit of reasoning.

The algorithm from the paper you posted in another comment indeed looks more complicated than it needs to be and prone to bad performance.

Judging by the design, it appears they were trying to avoid the local thread to touch the shared counter in any circumstance on the hot path, but I wonder if it would not be much simpler for the owner thread to just check a flag set by the non-owner thread and perform the unbiasing/freeing right away without going through all the queuing mechanism.