Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A viable solution for Python concurrency

lwn.net

Post reply on HN
Print view View original

121–130 of 366 posts

Re: A viable solution for Python concurrency

#121

Post by AgentME »

a1369209993 wrote: post #34

> 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, non-atomic instructions. Any other thread accessing the object will use atomic operations on the shared reference count. > Whenever the owning th…

>Edit: I probably should have explicitly noted that, as jetrink points out, the object is initialized with a atomic refcount of one (the "local refcount is nonzero" reference), and destroyed when the atomic refcount is one and to-be-decremented, so a purely local object never has atomic writes.

I think you're under the impression that the refcount would only ever need to be incremented if the object was shared to another thread, but that's not the case. The refcount isn't a count of how many threads have a reference to the object; it's a count of how many objects and closures have a reference to the object. Even objects that never leave their creator thread will be likely to have their reference count incremented and decremented a few times over their life.

Re: A viable solution for Python concurrency

#122

Post by kzrdude »

twic wrote: post #111
Jtsummers wrote: post #102

Earlier quoted context omitted.

Two spaces in front of each line of the code block. As written, right now, your comment is hard to parse: import threading def produce(): global global_foo local_foo = "potato" global_foo = local_foo def consume(): global global_foo local_foo = global_foo global_foo = None if __name__ == '__main__': produce() thread = threading.Thread(target=consume) thread.start() thread.join()

Sorry about that. I did indent before pasting the code - but gedit indents with tabs, which HN ignores!

It can be configured. I remember when Gedit was quite the potent editor, language plugins, snippets and stuff. But it has the basics left still :)

Re: A viable solution for Python concurrency

#123

Post by otterley »

Fordec wrote: post #118
otterley wrote: post #110

This may be a silly question, but if you really need concurrency, why not use a language that's built for concurrency from the ground up instead? Elixir is a great example.

Sometimes a project starts off aiming to solve a problem. maybe it's a data science problem, so support already exists in python so lets do that. Ok, it worked great and it's catching on with users. Now we need to scale, but we are running into concurrency issues. What is a better answer? Ok we will work on improving python concurrency under the hood, or completely scrap the code base and switch to a different langua…

I'll plead ignorance here: Do data science workflows often require high concurrency using a single interpreter? I thought all that stuff was compute-bound and parceled out to workers that farm out calculations to CPUs and GPUs.

Re: A viable solution for Python concurrency

#124

Post by EamonnMR »

ajkjk wrote: post #45
misnome wrote: post #2

> This "optimization" actually slows single-threaded accesses down slightly, according to the design document, but that penalty becomes worthwhile once multi-threaded execution becomes possible. My understanding was that CPython viewed any single-threaded performance regression as a blocker to GIL-removal attempts, regardless of if other work by the developer has sped up the interpreter? This article seems to somewha…

There are people who believe all kinds of crazy things; it doesn't reflect their truth. Going back to Python 2 is not going to ever happen (and no one working on Py3 would ever want to, anyway). A hard pill to swallow.. ain't that bad if it also benefits you tremendously, which fixing the GIL would do.

I do wish for a world where Python 3 had handled unicode/bytes very differently.

Re: A viable solution for Python concurrency

#125

Post by [deleted] »

typical182 wrote: post #66

This is a great list of influences on the design (from the article comments where the prototype author Sam Gross responded to someone wishing for more cross pollination across language communities): ————— "… but I'll give a few more examples specific to this project of ideas (or code) taken from other communities: - Biased reference counting (originally implemented for Swift) - mimalloc (originally developed for Koka…

[deleted]

Re: A viable solution for Python concurrency

#126

Post by a1369209993 »

AgentME wrote: post #121
a1369209993 wrote: post #34

> 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, non-atomic instructions. Any other thread accessing the object will use atomic operations on the shared reference count. > Whenever the owning th…

>Edit: I probably should have explicitly noted that, as jetrink points out, the object is initialized with a atomic refcount of one (the "local refcount is nonzero" reference), and destroyed when the atomic refcount is one and to-be-decremented, so a purely local object never has atomic writes. I think you're under the impression that the refcount would only ever need to be incremented if the object was shared to ano…

> Even objects that never leave their creator thread will be likely to have their reference count incremented and decremented a few times over their life.

I think you're under the impression that there's only one refcount. The point of the original design (and this one) is that there are two refcounts: one that's updated only by the thread that created the object, and therefor doesn't need to use slow atomic accesses, and one that's updated atomically, and therefor can be adjusted by arbitrary threads.

Re: A viable solution for Python concurrency

#127

Post by otterley »

ska wrote: post #114
otterley wrote: post #110

This may be a silly question, but if you really need concurrency, why not use a language that's built for concurrency from the ground up instead? Elixir is a great example.

To a first approximation, people don't use python for itself, they use it for the vast ecosystem and network effect. If you jump to another language for better concurrency, what are you giving up? Unless you really are doing greenfield development in an isolated application, these considerations often trump any language feature.

Don't get me wrong; I'm not suggesting that anyone dump Python altogether to switch to a different language for any arbitrary project or purpose. Many businesses I work with use different languages for different components or applications, using the network or storage (or even shared memory) to intercommunicate when necessary. The right tool for the job, as it were.

Re: A viable solution for Python concurrency

#128

Post by int_19h »

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.

How would those green/virtual threads interface with native async APIs (e.g. the entirety of WinRT)?

Re: A viable solution for Python concurrency

#129

Post by int_19h »

kzrdude wrote: post #86
mzs wrote: post #23

Yikes, C extensions can't assume they are under GIL by default: https://github.com/colesbury/numpy/commits/v1.19.3-nogil

It looks like a total of four lines needed changing in numpy due to his change. That's a very good score in my book, numpy is huge.

It really depends on how the library is written, and how much shared data it has. It has been very common to use GIL as a general-purpose synchronization mechanism in native Python modules, since you have to pay that tax either way.

Re: A viable solution for Python concurrency

#130

Post by veryupwork »

Jweb_Guru wrote: post #106
kzrdude wrote: post #86

Earlier quoted context omitted.

It looks like a total of four lines needed changing in numpy due to his change. That's a very good score in my book, numpy is huge.

Unfortunately, every C extension will need to undergo manual review for safety, unless there's some very easy way to have the C extension opt into using the GIL. And some of them will be close to impossible to detangle in this way.

no
Post reply on HN