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

The first year of free-threaded Python

labs.quansight.org

Post reply on HN
Print view View original

271–280 of 302 posts

Re: The first year of free-threaded Python

#271

Post by tgv »

jillesvangurp wrote: post #23
AlexanderDhoore wrote: post #2

Am I the only one who sort of fears the day when Python loses the GIL? I don't think Python developers know what they’re asking for. I don't really trust complex multithreaded code in any language. Python, with its dynamic nature, I trust least of all.

You are not the only one who is afraid of changes and a bit change resistant. I think the issue here is that the reasons for this fear are not very rational. And also the interest of the wider community is to deal with technical debt. And the GIL is pure technical debt. Defensible 30 years ago, a bit awkward 20 years ago, and downright annoying and embarrassing now that world + dog does all their AI data processing w…

> Nothing unless you start using threads.

Isn't it also promises/futures? They might start threads implicitly.

Re: The first year of free-threaded Python

#272

Post by kragen »

kragen wrote: post #251
wisty wrote: post #66

Earlier quoted context omitted.

It sounds like an oblique reference to that time they temporarily suspended one of the of the most valuable members of the community, apparently for having the audacity to suggest that their powers to suspend members of the community seemed a little arbitrary and open to abuse.

Temporarily? Tim Peters got reinstated?

Apparently so: https://lwn.net/Articles/1002340/

Re: The first year of free-threaded Python

#273

Post by bgwalter »

monkeyelite wrote: post #254
morkalork wrote: post #121

Earlier quoted context omitted.

Didn't Google lay off their entire Python development team in the last year as well? I wonder if there is some impetus behind both.

This is a story from a few years ago, and they obviously have lots of teams that use python. This team was an internal support for python and tools - which honestly sounds exactly like the kind of thing that would get cut in a pinch (no value judgement).

No, that story is from last year.

Re: The first year of free-threaded Python

#274

Post by foresto »

celeritascelery wrote: post #244
foresto wrote: post #166

Earlier quoted context omitted.

As I recall, CPython has also been getting speed-ups lately, which ought to make up for the minor single-threaded performance loss introduced by free threading. With that in mind, the recent changes seem like an overall win to me.

It’s not either/or. The CPython speedups would be even better with the single threaded interpreter.

Nobody has suggested otherwise.

Re: The first year of free-threaded Python

#275

Post by bgwalter »

bayindirh wrote: post #10
AlexanderDhoore wrote: post #2

Am I the only one who sort of fears the day when Python loses the GIL? I don't think Python developers know what they’re asking for. I don't really trust complex multithreaded code in any language. Python, with its dynamic nature, I trust least of all.

More realistically, as it happened in ML/AI scene, the knowledgeable people will write the complex libraries and will hand these down to scientists and other less experienced, or risk-averse developers (which is not a bad thing). With the critical mass Python acquired over the years, GIL becomes a very sore bottleneck in some cases. This is why I decided to learn Go, for example. Properly threaded (and green threaded…

Knowledgeable people? Pytorch has memory leaks by design, it uses std::shared_ptr for a graph with cycles. It also has threading issues.

Re: The first year of free-threaded Python

#276

Post by dontlaugh »

seabrookmx wrote: post #243
AlexanderDhoore wrote: post #2

Am I the only one who sort of fears the day when Python loses the GIL? I don't think Python developers know what they’re asking for. I don't really trust complex multithreaded code in any language. Python, with its dynamic nature, I trust least of all.

While it certainly has its rough edges, I'm a big asyncio user. So I'll be over here happily writing concurrent python that's single threaded, ie. pretending my Python is nodejs. For the web/network workloads most of us write, I'd highly recommend this.

Asyncio being able to use thread pools would reduce memory usage at the very least.

Re: The first year of free-threaded Python

#277

Post by perlgeek »

sgarland wrote: post #48

> Instead, many reach for multiprocessing, but spawning processes is expensive Agreed. > and communicating across processes often requires making expensive copies of data SharedMemory [0] exists. Never understood why this isn’t used more frequently. There’s even a ShareableList which does exactly what it sounds like, and is awesome. [0]: https://docs.python.org/3/library/multiprocessing.shared_mem...

> Never understood why this isn’t used more frequently.

Can you throw a JSON-serializable data structure (lists, dict, strings, numbers) into SharedMemory? What about regular instance of random Python classes? If the answer is "no", that explains why it's not done more often.

The examples in the docs seem to pass byte strings and byte arrays around, which is far less convenient than regular data structures.

Re: The first year of free-threaded Python

#278

Post by dragonwriter »

perlgeek wrote: post #277
sgarland wrote: post #48

> Instead, many reach for multiprocessing, but spawning processes is expensive Agreed. > and communicating across processes often requires making expensive copies of data SharedMemory [0] exists. Never understood why this isn’t used more frequently. There’s even a ShareableList which does exactly what it sounds like, and is awesome. [0]: https://docs.python.org/3/library/multiprocessing.shared_mem...

> Never understood why this isn’t used more frequently. Can you throw a JSON-serializable data structure (lists, dict, strings, numbers) into SharedMemory? What about regular instance of random Python classes? If the answer is "no", that explains why it's not done more often. The examples in the docs seem to pass byte strings and byte arrays around, which is far less convenient than regular data structures.

> Can you throw a JSON-serializable data structure (lists, dict, strings, numbers) into SharedMemory?

You can throw a JSON-serialized data structure into SharedMemory, sure, since you can store strings.

> The examples in the docs seem to pass byte strings and byte arrays around

The examples in the docs largely use ShareableList, which itself can contain any of int, float, bool, str, bytes, and None-type values.

Re: The first year of free-threaded Python

#279

Post by dragonwriter »

com2kid wrote: post #165
modeless wrote: post #109

Earlier quoted context omitted.

Yeah I've had great success sharing numpy arrays this way. Explicit sharing is not a huge burden, especially when compared with the difficulty of debugging problems that occur when you accidentally share things between threads. People vastly overstate the benefit of threads over multiprocessing and I don't look forward to all the random segfaults I'm going to have to debug after people start routinely disabling the G…

> I wonder why people never complained so much about JavaScript not having shared-everything threading. Maybe because JavaScript is so much faster that you don't have to reach for it as much. I wish more effort was put into baseline performance for Python. Nobody sane tries to do math in JS. Backend JS is recommended for situations where processing is minimal and it is mostly lots of tiny IO requests that need to be…

> For some reason Python peeps keep trying to do actual computations in Python...

Mostly, Python peeps do heavy calculation in not-really-Python (even if it is embedded in and looks like Python), e.g., via numpy, numba, taichi, etc.

Re: The first year of free-threaded Python

#280

Post by diziet_sma »

MichaelMoser123 wrote: post #263

cpython doesn't have a JIT, why is free-threaded python a higher priority than developing a just in time compiler? The later would be more resonant with the typical use case for python and benefit a larger portion of users, wouldn't it? (Wouldn't a backend server project use golang or java to begin with?)

There have been many attempts to make a Python JIT that is compatible with CPython to various levels of success. However the larger reason is that the gains from removing the GIL far exceeds the gains from a JIT.

If you're writing performance sensitive python code, the "hot" code is likely already in a C-extension, such as Numpy. So there is negligible benefit to running the code with a JIT.

Post reply on HN