A viable solution for Python concurrency • Hacker News Board

Re: A viable solution for Python concurrency

#311

Post by jgehrcke » Sat, Oct 16, 2021, 1:15 PM UTC

btown wrote: post #97

ferdowsi wrote: post #11

If this effort succeeds (and I hope it does) now Python developers will need to contend with the event-loop albatross of asyncio and all of its weird complexity. In an alternate Python timeline, asyncio was not introduced into the Python standard library, and instead we got a natively supported, robust, easy-to-use concurrency paradigm built around green/virtual threading that accommodates both IO and CPU bound work.

> instead we got a natively supported, robust, easy-to-use concurrency paradigm built around green/virtual threading that accommodates both IO and CPU bound work Minus the "natively supported" part, we have this today in http://www.gevent.org/ ! It's so, so empowering to be able to access the entire historical body of work of synchronous-I/O Python libraries, and with a single monkey patch cause every I/O operation,…

This!

> gevent doesn't have good support for multiprocessing

This is where my little library https://github.com/jgehrcke/gipc might help! It's been working well for people since 2012 :)

By the way, gevent is huge for the Python ecosystem and I would love to acknowledge both Denis Bilenko and Jason Madden who have done a great job over the years. I am in particular impressed by Jason's maintenance work -- creating a new project is always exciting. Maintaining it over the years is sometimes just tedious, hard work. Jason has impressed me a lot with his one man show there.

Not sure if everybody knows, but gevent was for starters built on top of "only" libev -- another super impressive project built and maintained by practically a single person: Marc Lehmann. I learned a lot from his work, too. So so so many serious software projects build on top of libev.

Only 'recently' gevent included support for libuv, the event loop that originated from the NodeJS ecosystem.

I find it super interesting to see that CPython+gevent+libuv is highly similar to running NodeJS!

By the way, the LWN article is once again a wonderfully written piece by Jonathan Corbet. His way to doing technical writing is simply great, I have enjoyed it very much over the years and learned a lot.

Re: A viable solution for Python concurrency

#312

Post by Too » Sat, Oct 16, 2021, 1:19 PM UTC

fullstop wrote: post #28

tbabb wrote: post #19

Earlier quoted context omitted.

What specifically is the problem with asyncio? I quite like using it, so I'm curious if there's some aspect that makes it unsustainable?

I like using it as well, but I've been bit several times by having runtime exceptions completely swallowed.

Let me guess. Using create_task() without await and assuming it will run to completion in the background to trigger some other event?

This is almost always the case of async tasks disappearing into the void. After shooting myself in the foot with this one time to many I have a hard rule to never use create_task. Instead make sure every single task ends up in some kind of gather() or wait() awaited from the top level. This will ensure any exceptions are propagated. If the number of tasks are dynamically created, while others are still ongoing, add them to a common list and restart your wait() call.

Re: A viable solution for Python concurrency

#313

Post by jgehrcke » Sat, Oct 16, 2021, 1:20 PM UTC

zzzeek wrote: post #211

throwaway81523 wrote: post #164

Earlier quoted context omitted.

The entire Python community was in pain over Python 3 for 10 years, even if migrating any particular program wasn't much trouble. If you want to contest the notion that there was pain, then fine: most of the community simply ignored Python 3 for 10 years, because there was no reason until quite late in the process to worry about it. I myself never bothered migrating any of my Python 2 stuff. It might not be difficult…

And yet python tops the Tiobe index anyway. The python 3 transition was not that big a deal, and I migrated or assisted in the migration of many codebases some of which are as big as they get (openstack). the ten year thing especially made it really gradual, and we're all done now. Python 3 is great. Folks migrating to rust / go etc are looking at performance concerns for high volume server software, which python is…

By the way Mike I think https://techspot.zzzeek.org/2015/02/15/asynchronous-python-a... is still one of the best articles on the topic of "python and concurrency". So many important insights for real-world engineering.

Thanks for all your work in the Python ecosystem!

Re: A viable solution for Python concurrency

#314

Post by profquail » Sat, Oct 16, 2021, 1:48 PM UTC

qstwall wrote: post #276

It is hard to see the point of a GIL removal that will destabilize the C extension ecosystem for probably a decade again: C extensions can already start as many threads as they like. Threaded pure Python, even if GIL-less, is still slow, so what is the point? The whole point of Python (before asyncio, pattern matching etc.) was being simple and having a nice C interface. If that continues to erode, people will (and s…

Now could be a good time to make this change, in coordination with HPy: https://github.com/hpyproject/hpy

I agree though — it’s tempting to keep extending and stretching the language to be something it was never designed for; but at some point it’s been stretched so far it loses the properties that made it attractive to start with. I like Python, but some of the things people are using it for now, they should really consider another language instead, and write a Python wrapper on top of that if they must use it from Python.

Re: A viable solution for Python concurrency

#315

Post by SoylentOrange » Sat, Oct 16, 2021, 1:51 PM UTC

qstwall wrote: post #279

SoylentOrange wrote: post #231

Earlier quoted context omitted.

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

It will still be slow if the threaded code is in pure Python.

> When pointed to the "ccbench" benchmark, Gross reported speedups of 18-20x when running with 20 threads.

I would be very happy with that, together with a 10% speed increase in single-threaded performance that they said would come as a result of these changes.

Re: A viable solution for Python concurrency

#316

Post by SoylentOrange » Sat, Oct 16, 2021, 1:57 PM UTC

rmbyrro wrote: post #239

SoylentOrange wrote: post #229

Earlier quoted context omitted.

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.

That’s true you’re right. But I’ve heard others talk about adding a JIT, which would likely be a large breaking change at the ABI level.

Re: A viable solution for Python concurrency

#317

Post by Tronchenbiais » Sat, Oct 16, 2021, 2:09 PM UTC

Regarding the implementation of this, I am surprised by the use of the least significant bits of the local ref count to hold what are essentially flags telling whether the reference is immortal or deferred. This sounds like a ugly hack, and as pointed out by the article, will break existing C code manipulating the count directly without using the associated macros (although arguably, doing this is unspecified, and really it's their fault).

My guess is that this was done for memory efficiency, but is there really no way to have the local refcount be a packed struct or something, where the "count" field holds the real ref count and the flags are stored separately? I have no understanding of the CPython internals, so it may very well be impossible, but I would appreciate someone explaining why.

Re: A viable solution for Python concurrency

#318

Post by zzzeek » Sat, Oct 16, 2021, 2:55 PM UTC

tialaramex wrote: post #247

zzzeek wrote: post #211

Earlier quoted context omitted.

And yet python tops the Tiobe index anyway. The python 3 transition was not that big a deal, and I migrated or assisted in the migration of many codebases some of which are as big as they get (openstack). the ten year thing especially made it really gradual, and we're all done now. Python 3 is great. Folks migrating to rust / go etc are looking at performance concerns for high volume server software, which python is…

However if you're confident Python simply is "never going to specialize in" performance, maybe the GIL isn't a problem and this work is irrelevant right? I'm dubious about this work because I think it tries to paper over the cracks in code with data races, but maybe the problem was there already with the GIL and this changes little.

I agree, the GIL is really not a huge problem unless you are trying to write a high frequency trading app in Python, which you shouldn't (and not just for technical reasons ;) )

Re: A viable solution for Python concurrency

#319

Post by willseth » Sat, Oct 16, 2021, 3:08 PM 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,…

> This just feels fighting the seemingly inevitable fate of Python.

Which is what, exactly? If you’re suggesting that devs will lose interest in Python then you’re simply not paying attention. Python is _gaining_ in popularity, over Java, C, even JS. It’s not that control over typing isn’t an issue, but developers are undeterred.

Re: A viable solution for Python concurrency

#320

Post by otterley » Sat, Oct 16, 2021, 3:14 PM UTC

rattray wrote: post #219

game_the0ry wrote: post #200

I might have a controversial or unpopular opinion - I do not think python should try to be concurrent or any more performant than it already is. Python is the tool I pick for quick scripting, not for highly performant systems - there are languages and run times for that. Sometime highly productive software does not need to be highly performant, and that does not make the software any more or less valuable. And someti…

> Python is the tool I pick ... not for highly performant systems Many high-throughput, high-concurrency systems run on Python, famously including Instagram and Pinterest (which see quite a lot of traffic).

Are the performance-critical components of these sites written in Python? That’s the question.