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

191–200 of 302 posts

Re: The first year of free-threaded Python

#191

Post by make3 »

bgwalter wrote: post #47
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.

They were quite a bit behind the schedule that was promised five years ago. Additionally, at this stage the severe political and governance problems cannot have escaped Microsoft. I imagine that no competent Microsoft employee wants to give his expertise to CPython, only later to suffer group defamation from a couple of elected mediocre people. CPython is an organization that overpromises, allocates jobs to the obedi…

Microsoft also fired a whole lot of other open source people unrelated to Python in this current layoff

Re: The first year of free-threaded Python

#192

Post by make3 »

morkalork wrote: post #121
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.

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.

doesn't print money right away = cut by executive #3442

Re: The first year of free-threaded Python

#193

Post by make3 »

I hate how these threads always devolve in insane discussions about why not using threads is better, while most real world people who have tried to do real world speeding up of Python code realize how amazing it would be to have proper threads with shared memory instead of the processes that have so many limitations, like forcing to pickle objects back and forth, & fork so often just not working in the cloud setting, & spawn being so slow in a lot of applications. The usage of processes is just much heavier and less straightforward.

Re: The first year of free-threaded Python

#194

Post by knome »

charleshn wrote: post #168
chubot wrote: post #112

Earlier quoted context omitted.

Spawning processes generally takes much less than 1 ms on Unix Spawning a PYTHON interpreter process might take 30 ms to 300 ms before you get to main(), depending on the number of imports It's 1 to 2 orders of magnitude difference, so it's worth being precise This is a fallacy with say CGI. A CGI in C, Rust, or Go works perfectly well. e.g. sqlite.org runs with a process PER REQUEST - https://news.ycombinator.com/it…

> Spawning processes generally takes much less than 1 ms on Unix It depends on whether one uses clone, fork, posix_spawn etc. Fork can take a while depending on the size of the address space, number of VMAs etc.

for glibc and linux, fork just calls clone. as does posix_spawn, using the flag CLONE_VFORK.

Re: The first year of free-threaded Python

#195

Post by kragen »

btilly wrote: post #163
Sharlin wrote: post #117

Earlier quoted context omitted.

Unix is not the only platform though (and is process creation fast on all Unices or just Linux?) The point about interpreter init overhead is, of course, apt.

Process creation should be fast on all Unices. If it isn't, then the lowly shell script (heavily used in Unix) is going to perform very poorly.

While I think you've been using Unix longer than I have, shell scripts are known for performing very poorly, and on PDP-11 Unix (where perhaps shell scripts were most heavily used, since Perl didn't exist yet) fork() couldn't even do copy-on-write; it had to literally copy the process's entire data segment, which in most cases also contained a copy of its code. Moving to paged machines like the VAX and especially the 68000 family made it possible to use copy-on-write, but historically speaking, Linux has often been an order of magnitude faster than most other Unices at fork(). However, I think people mostly don't use those Unices anymore. I imagine the BSDs have pretty much caught up by now.

https://news.ycombinator.com/item?id=44009754 gives some concrete details on fork() speed on current Linux: 50μs for a small process, 700μs for a regular process, 1300μs for a venti Python interpreter process, 30000–50000μs for Python interpreter creation. This is on a CPU of about 10 billion instructions per second per core, so forking costs on the order of ½–10 million instructions.

Re: The first year of free-threaded Python

#196

Post by kubb »

forrestthewoods wrote: post #162
henry700 wrote: post #160

I find it peculiar how, in a language so riddled with simple concurrency architectural issues, the approach is to painstankingly fix every library after fixing the runtime, instead of just using some better language. Why does the community insist on such a bad language when literally even fucking Javascript has a saner execution model?

> instead of just using some better language Python the language is pretty bad. Python the ecosystem of libraries and tools has no equal, unfortunately. Switching a language is easy. Switching a billion lines of library less so. And the tragic part is that many of the top “python libraries” are just Python interfaces to a C library! But if you want to switch to a “better language” that fact isn’t helpful.

I wonder if we get automatic LLM translation of codebases from language to language soon - this could close the library gap and diminish the language lock in factor.

Re: The first year of free-threaded Python

#197

Post by kragen »

chubot wrote: post #112
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...

Spawning processes generally takes much less than 1 ms on Unix Spawning a PYTHON interpreter process might take 30 ms to 300 ms before you get to main(), depending on the number of imports It's 1 to 2 orders of magnitude difference, so it's worth being precise This is a fallacy with say CGI. A CGI in C, Rust, or Go works perfectly well. e.g. sqlite.org runs with a process PER REQUEST - https://news.ycombinator.com/it…

To be concrete about this, http://canonical.org/~kragen/sw/dev3/forkovh.c took 670μs to fork, exit, and wait on the first laptop I tried it on, but only 130μs compiled with dietlibc instead of glibc, and with glibc on a 2.3 GHz E5-2697 Xeon, it took 130μs compiled with glibc.

httpdito http://canonical.org/~kragen/sw/dev3/server.s (which launches a process per request) seems to take only about 50μs because it's not linked with any C library and therefore only maps 5 pages. Also, that doesn't include the time for exit() because it runs multiple concurrent child processes.

On this laptop, a Ryzen 5 3500U running at 2.9GHz, forkovh takes about 330μs built with glibc and about 130–140μs built with dietlibc, and `time python3 -c True` takes about 30000–50000μs. I wrote a Python version of forkovh http://canonical.org/~kragen/sw/dev3/forkovh.py and it takes about 1200μs to fork(), _exit(), and wait().

If anyone else wants to clone that repo and test their own machines, I'm interested to hear the results, especially if they aren't in Linux. `make forkovh` will compile the C version.

1200μs is pretty expensive in some contexts but not others. Certainly it's cheaper than spawning a new Python interpreter by more than an order of magnitude.

Re: The first year of free-threaded Python

#198

Post by jaoane »

chubot wrote: post #112
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...

Spawning processes generally takes much less than 1 ms on Unix Spawning a PYTHON interpreter process might take 30 ms to 300 ms before you get to main(), depending on the number of imports It's 1 to 2 orders of magnitude difference, so it's worth being precise This is a fallacy with say CGI. A CGI in C, Rust, or Go works perfectly well. e.g. sqlite.org runs with a process PER REQUEST - https://news.ycombinator.com/it…

>Spawning a PYTHON interpreter process might take 30 ms to 300 ms before you get to main(), depending on the number of imports

That's lucky. On constrained systems launching a new interpreter can very well take 10 seconds. Python is ssssslllloooowwwww.

Re: The first year of free-threaded Python

#199

Post by pphysch »

fjasdfas wrote: post #147
pphysch wrote: post #116

Earlier quoted context omitted.

But the bar to parallelizing code gets much lower, in theory. Your serial code got 5% slower but has a direct path to being 50% faster. And if there's a good free-threaded HTTP server implementation, the RPS of "Python code as a whole" could increase dramatically.

You can do multiple processes with SO_REUSEPORT. free-threaded makes sense if you need shared state.

Any webserver that wants to cache and reuse content cares about shared state, but usually has to outsource that to a shared in-memory database because the language can't support it.

Re: The first year of free-threaded Python

#200

Post by pjmlp »

make3 wrote: post #191
bgwalter wrote: post #47

Earlier quoted context omitted.

They were quite a bit behind the schedule that was promised five years ago. Additionally, at this stage the severe political and governance problems cannot have escaped Microsoft. I imagine that no competent Microsoft employee wants to give his expertise to CPython, only later to suffer group defamation from a couple of elected mediocre people. CPython is an organization that overpromises, allocates jobs to the obedi…

Microsoft also fired a whole lot of other open source people unrelated to Python in this current layoff

Notably MAUI, ASP.NET, Typescript and AI frameworks.
Post reply on HN