The first year of free-threaded Python

Post by notpushkin » Fri, May 16, 2025, 6:23 PM UTC

rfoo wrote: post #142

celeritascelery wrote: post #98

Earlier quoted context omitted.

> That's the trade-off. Personally I think a single digit percentage slow-down of single-threaded code worth it. Maybe. I would expect that 99% of python code going forward will still be single threaded. You just don’t need that extra complexity for most code. So I would expect that python code as a whole will have worse performance, even though a handful of applications will get faster.

That's the mindset that leads to the funny result that `uv pip` is like 10x faster than `pip`. Is it because Rust is just fast? Nope. For anything after resolving dependency versions raw CPU performance doesn't matter at all. It's writing concurrent PLUS parallel code in Rust is easier, doesn't need to spawn a few processes and wait for the interpreter to start in each, doesn't need to serialize whatever shit you wan…

Post by jdsleppy » Fri, May 16, 2025, 6:50 PM UTC

sylware wrote: post #97

Got myself a shiny python 3.13.3 (ssl module still unable to compile with libressl) replacing a 3.12.2, feels clearly slower. What's wrong?

Post by LPisGood » Fri, May 16, 2025, 7:14 PM UTC

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…

Post by rbanffy » Fri, May 16, 2025, 7:37 PM UTC

cestith wrote: post #84

bayindirh wrote: post #42

Earlier quoted context omitted.

Software rots, software tools evolve. When Intel released performance primitives libraries which required recompilation to analyze multi-threaded libraries, we were amazed. Now, these tools are built into processors as performance counters and we have way more advanced tools to analyze how systems behave. Older code will break, but they break all the time. A language changes how something behaves in a new revision, s…

My only concern is this kind of change in semantics for existing syntax is more worthy of a major revision than a point release.

Post by wahern » Fri, May 16, 2025, 7:55 PM UTC

jcalvinowens wrote: post #170

wongarsu wrote: post #156

Earlier quoted context omitted.

> In contrast, no one thinks about what happens if a thread dies independently because the failure mode is joint. In Rust if a thread holding a mutex dies the mutex becomes poisoned, and trying to acquire it leads to an error that has to be handled. As a consequence every rust developer that touches a mutex has to think about that failure mode. Even if in 95% of cases the best answer is "let's exit when that happens"…

> But a thread can still crash in its own due to unhandled oom, assertion failures or any number of other issues That's not really true on POSIX. Unless you're doing nutty things with clone(), or you actually have explicit code that calls pthread_exit() or gettid()/pthread_kill(), the whole process is always going to die at the same time. POSIX signal dispositions are process-wide, the only way e.g. SIGSEGV kills a s…