The first year of free-threaded Python • Hacker News Board

Re: The first year of free-threaded Python

#251

Post by kragen » Sat, May 17, 2025, 3:08 AM UTC

wisty wrote: post #66

biorach wrote: post #60

Earlier quoted context omitted.

> CPython is an organization that overpromises, allocates jobs to the obedient and faithful while weeding out competent dissenters. This stinks of BS

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?

Re: The first year of free-threaded Python

#252

Post by kragen » Sat, May 17, 2025, 3:12 AM UTC

kragen wrote: post #197

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…

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 li…

On my cellphone forkovh is 700μs and forkovh.py is 3700μs. Qualcomm SDM630. All the forkovh numbers are with 102400 bytes of data.

Re: The first year of free-threaded Python

#253

Post by monkeyelite » Sat, May 17, 2025, 3:32 AM UTC

modeless wrote: post #109

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 G…

> I wonder why people never complained so much about JavaScript not having shared-everything threading

Because it greatly simplifies the language and gives you all kinds of invariants.

Re: The first year of free-threaded Python

#254

Post by monkeyelite » Sat, May 17, 2025, 3:35 AM UTC

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.

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

Re: The first year of free-threaded Python

#255

Post by monkeyelite » Sat, May 17, 2025, 3:38 AM UTC

pansa2 wrote: post #19

Does removal of the GIL have any other effects on multi-threaded Python code (other than allowing it to run in parallel)? My understanding is that the GIL has lasted this long not because multi-threaded Python depends on it, but because removing it: - Complicates the implementation of the interpreter - Complicates C extensions, and - Causes single-threaded code to run slower Multi-threaded Python code already has to…

Yes it makes every part of the ecosystem more complex and prone to bugs in hopes of getting more performance in a scripting language.

Re: The first year of free-threaded Python

#256

Post by monkeyelite » Sat, May 17, 2025, 3:40 AM UTC

pphysch wrote: post #199

fjasdfas wrote: post #147

Earlier quoted context omitted.

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.

And most web servers already need in memory databases for other things. And it’s a great design principle - use sharp focused tools.

Re: The first year of free-threaded Python

#257

Post by monkeyelite » Sat, May 17, 2025, 3:40 AM UTC

rocqua wrote: post #126

rfoo wrote: post #26

Earlier quoted context omitted.

> Does free-threaded Python provide the same guarantees Mostly. Some of the "can be pre-empted on the boundary between any two bytecode instructions" bugs are really hard to hit without free-threading, though. And without free-threading people don't use as much threading stuff. So by nature it exposes more bugs. Now, my rants: > have any other effects on multi-threaded Python code It stops people from using multi-pro…

Note that there is an entire order of magnitude range for a 'single digit'. A 1% slowdown seems totally fine. A 9% slowdown is pretty bad.

If so, then why use python?

Re: The first year of free-threaded Python

#258

Post by monkeyelite » Sat, May 17, 2025, 3:44 AM UTC

miohtama wrote: post #6

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.

GIL or no-GIL concerns only people who want to run multicore workloads. If you are not already spending time threading or multiprocessing your code there is practically no change. Most race condition issues which you need to think are there regardless of GIL.

When you launch processes to do work you get multi-core workload balancing for free.

Re: The first year of free-threaded Python

#259

Post by monkeyelite » Sat, May 17, 2025, 3:45 AM UTC

freeone3000 wrote: post #35

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.

I'm sure you'll be happy using the last language that has to fork() in order to thread. We've only had consumer-level multicore processors for 20 years, after all.

I don’t understand this argument. My python program isn’t the only program on the system - I have a database, web server, etc. It’s already multi-core.

Re: The first year of free-threaded Python

#260

Post by spacechild1 » Sat, May 17, 2025, 3:50 AM UTC

amelius wrote: post #58

bratao wrote: post #55

Earlier quoted context omitted.

This is a common mistake and very badly communicated. The GIL do not make the Python code thread-safe. It only protect the internal CPython state. Multi-threaded Python code is not thread-safe today.

Well, I think you can manipulate a dict from two different threads in Python, today, without any risk of segfaults.

It's memory safe, but it's not necessarily free of race conditions! It's not only C extensions that release the GIL, the Python interpreter itself releases the GIL after a certain number of instructions so that other threads can make progress. See https://docs.python.org/3/library/sys.html#sys.getswitchinte....

Certain operations that look atomic to the user are actually comprised of multiple bytecode instructions. Now, if you are unlucky, the interpreter decides to release the GIL and yield to another thread exactly during such instructions. You won't get a segfault, but you might get unexpected results.