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

101–110 of 302 posts

Re: The first year of free-threaded Python

#101

Post by tomrod »

ogrisel wrote: post #53
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...

You cannot share arbitrarily structured objects in the `ShareableList`, only atomic scalars and bytes / strings. If you want to share structured Python objects between instances, you have to pay the cost of `pickle.dump/pickle.dump` (CPU overhead for interprocess communication) + the memory cost of replicated objects in the processes.

I can fit a lot of json into bytes/strings though?

Re: The first year of free-threaded Python

#102

Post by cjbgkagh »

tomrod wrote: post #101
ogrisel wrote: post #53

Earlier quoted context omitted.

You cannot share arbitrarily structured objects in the `ShareableList`, only atomic scalars and bytes / strings. If you want to share structured Python objects between instances, you have to pay the cost of `pickle.dump/pickle.dump` (CPU overhead for interprocess communication) + the memory cost of replicated objects in the processes.

I can fit a lot of json into bytes/strings though?

Perhaps flatbuffers would be better?

Re: The first year of free-threaded Python

#103

Post by vlovich123 »

tomrod wrote: post #101
ogrisel wrote: post #53

Earlier quoted context omitted.

You cannot share arbitrarily structured objects in the `ShareableList`, only atomic scalars and bytes / strings. If you want to share structured Python objects between instances, you have to pay the cost of `pickle.dump/pickle.dump` (CPU overhead for interprocess communication) + the memory cost of replicated objects in the processes.

I can fit a lot of json into bytes/strings though?

That’s even worse than pickle.

Re: The first year of free-threaded Python

#104

Post by tomrod »

bgwalter wrote: post #32

This is just an advertisement for the company. Fact is, free-threading is still up to 50% slower, the tail call interpreter isn't much faster at all, and free-threading is still flaky. Things they won't tell you at PyCon.

QuantSight isn't a formal company though, it's a skunkworks/OSS research group run by the Travis Oliphant.

Re: The first year of free-threaded Python

#106

Post by vlovich123 »

pjmlp wrote: post #40

On the other news, Microsoft dumped the whole faster Python team, apparently the 2025 earnings weren't enough to keep the team around. https://www.linkedin.com/posts/mdboom_its-been-a-tough-coupl... Lets see whatever performance improvements still land on CPython, unless other company sponsors the work. I guess Facebook (no need to correct me on the name) is still sponsoring part of it.

That’s unfortunate but I called it when people were claiming that Microsoft had committed to this effort for the long term.

Re: The first year of free-threaded Python

#109

Post by modeless »

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

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 GIL in a library ecosystem that isn't ready.

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.

Re: The first year of free-threaded Python

#110

Post by gchamonlive »

aitchnyu wrote: post #108

Whats currently stopping me (apart from library support) from running a single command that starts up WSGI workers and Celery workers in a single process?

Nothing, it's just that these aren't first class features of the language. Also someone already explained that the GIL is mostly about technical debt in the CPython interpreter, so there are reasons other than full parallelism to get rid of the GIL.
Post reply on HN