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

261–270 of 302 posts

Re: The first year of free-threaded Python

#261

Post by monkeyelite »

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.

Good engineering design is about making unbalanced tradeoffs where you get huge wins for low costs. These kinds of decisions are opinionated and require you to say no to some edge cases to get a lot back on the important cases.

One lesson I have learned is that good design cannot survive popularity and bureaucracy that comes with it. Over time people just beat down your door with requests to do cases you explicitly avoided. You’re blocking their work and not being pragmatic! Eventually nobody is left to advocate for them.

And part of that is the community has more resources and can absorb some more complexity. But this is also why I prefer tools with smaller communities.

Re: The first year of free-threaded Python

#262

Post by csense »

zahlman wrote: post #214
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 wish more effort was put into baseline performance for Python. There has been. That's why the bytecode is incompatible between minor versions. It was a major selling(?) point for 3.11 and 3.12 in particular. But the "Faster CPython" team at Microsoft was apparently just laid off ( https://www.linkedin.com/posts/mdboom_its-been-a-tough-coupl... ), and all of the optimization work has to my understanding been based…

Yeah, when I'm having Python performance issues, my first instinct is to reach for Pypy. My second instinct is to rewrite the "hot" part in C or Rust.

Re: The first year of free-threaded Python

#263

Post by MichaelMoser123 »

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

Re: The first year of free-threaded Python

#264

Post by codethief »

morningsam wrote: post #201
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 a PYTHON interpreter process might take 30 ms to 300 ms Which is why, at least on Linux, Python's multiprocessing doesn't do that but fork()s the interpreter, which takes low-single-digit ms as well.

> Which is why, at least on Linux, Python's multiprocessing doesn't do that but fork()s the interpreter

…which can also be a great source of subtle bugs if you're writing a cross-platform application.

Re: The first year of free-threaded Python

#265

Post by necovek »

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.

Python already has a history of "misrepresenting" the ycope of the change (like changing behaviour of one of core data types and calling it just a major version change — that's really a new language IMHO).

Still, that's only a marketing move, technically the choice was still the right one, just like this one is.

Re: The first year of free-threaded Python

#266

Post by Too »

kstrauser wrote: post #226
zahlman wrote: post #209

Earlier quoted context omitted.

Even when the 'spawn' strategy is used (default on Windows, and can be chosen explicitly on Linux), the overhead can largely be avoided. (Why choose it on Linux? Apparently forking can cause problems if you also use threads.) Python imports can be deferred (`import` is a statement , not a compiler or pre-processor directive), and child processes (regardless of the creation strategy) name the main module as `__mp_main…

I really wish Python had a way to annotate things you don't care about cleaning up. I don't know what the API would look like, but I imagine something like: l = list(cleanup=False) for i in range(1_000_000_000): l.append(i) telling the runtime that we don't need to individually GC each of those tiny objects and just let the OS's process model free the whole thing at once. Sure, close TCP connections before you kill t…

Never experienced this. If this is truly a problem, here is a sledgehammer, just beware it will not close your tcp connections gracefully: os.kill(os.getpid(), signal.SIGKILL).

Re: The first year of free-threaded Python

#267

Post by Too »

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…

In Python, if you are spawning processes or even threads in a tight loop you have already lost. Use ThreadPoolExecutor or ProcessPoolExecutor from concurrent.futures instead. Then startup time becomes no factor.

Re: The first year of free-threaded Python

#268

Post by Too »

spookie wrote: post #145
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…

The other day I compiled a 1989 C program and it did the job. I wish more things were like that. Tired of building things on shaky grounds.

Hello world without -O2 -Werror? I've done several compiler toolchain updates on larger code bases and every new version of Clang, GCC or glibc will trip up new compiler warnings. Worse, occasionally taking advantage of some UB laying around leading to runtime bugs.

I'm not complaining, the new stricter warnings are usually for the better, what I'm saying is that the bedrock of that world isn't as stable as it's sometimes portraited.

Re: The first year of free-threaded Python

#269

Post by saagarjha »

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.

Yes, this is why using shell scripts on macOS is miserable

Re: The first year of free-threaded Python

#270

Post by UltraSane »

dkarl wrote: post #83
jillesvangurp wrote: post #23

Earlier quoted context omitted.

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…

> What changes for you? Nothing unless you start using threads Coming from the Java world, you don't know what you're missing. Looking inside an application and seeing a bunch of threadpools managed by competing frameworks, debugging timeouts and discovering that tasks are waiting more than a second to get scheduled on the wrong threadpool, tearing your hair out because someone split a tiny sub-10μs bit of computatio…

Just consider that mess job security!
Post reply on HN