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

231–240 of 302 posts

Re: The first year of free-threaded Python

#231

Post by zahlman »

kstrauser wrote: post #124
YouWhy wrote: post #65

Hey, I've been developing professionally with Python for 20 years, so wanted to weigh in: Decent threading is awesome news, but it only affects a small minority of use cases. Threads are only strictly necessary when it's prohibitive to message pass. The Python ecosystem these days includes a playbook solution for literally any such case. Considering the multiple major pitfalls of threads (i.e., locking), they are lik…

I haven’t been using it that much longer than you, and I agree with most of what you’re saying, but I’d characterize it differently. Python has a lot of solid workarounds for avoid threading because until now Python threading has absolutely sucked. I had naively tried to use it to make a CPU-bound workload twice as fast and soon realized the implications of the GIL, so I threw all that code away and made it multiproc…

> That sucked in its own way because I had to serialize lots of large data structures to pass around, so 2x the cores got me about 1.5x the speed and a warmer server room.

In many cases you can't reasonably expect better than that (https://en.wikipedia.org/wiki/Amdahl's_law). If your algorithm involves sharing "large data structures" in the first place, that's a bad sign.

Re: The first year of free-threaded Python

#232

Post by nyanpasu64 »

nothrabannosir wrote: post #123
jerrygenser wrote: post #120

Earlier quoted context omitted.

Ok so a better example of what you describe might be vscode.

What existing open standard did vscode Embrace? I thought Microsoft created v0 themselves. A classic example is ActiveX.

Microsoft "embraced" open-source ecosystems with an "open-source" editor, extended it with proprietary extensions DRMed to binary blobs hidden in VS Code binary builds, and used it to extinguish SSH, Python, C++, etc. development in open-source and derivative works of VS Code.

Re: The first year of free-threaded Python

#233

Post by zahlman »

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…

You'd presumably need to do something involving weakrefs, since it would be really bad if you told Python that the elements can be GCd at all (never mind whether it can be done all at once) but someone else had a reference.

Or completely rearchitect the language to have a model of automatic (in the C sense) allocation. I can't see that ever happening.

Re: The first year of free-threaded Python

#234

Post by nyanpasu64 »

kstrauser wrote: post #135
biorach wrote: post #125

Earlier quoted context omitted.

None of those were independent projects or open standards. VScode and pyright are both MS projects from the get-go. Sabotaging forks is scummy, but the forks were extending MS functionality, not the other way around. GitHub was a private company before it was bought by MS. Rate limiting is.... not great, but certainly not an extinguish play. EEE refers to the subversion of open standards or independent free software…

It’s not just EEE, though. They have a history of getting devs all in on a thing and then killing it with corporate-grade ADHD. They bought Visual FoxPro, got bored with it, and told everyone to rewrite into Visual Basic (which they then killed). Then the future was Silverlight, until it wasn’t. There are a thousand of these things that weren’t deliberately evil in the EEE, but defined the word rugpull before we call…

I'm more upset that Microsoft is charging money for using a code generation model trained on copyleft code.

Re: The first year of free-threaded Python

#235

Post by notpushkin »

notpushkin wrote: post #180
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.

We need a dataclass-like interface on top of a ShareableList.

Actually, ShareableList feels like a tuple really (as it’s impossible to change its length). If we could mix ShareableList and collections.namedtuple together, it would get us 90% there (99.9% if we use typing.NamedTuple). Unfortunately, I can’t decipher either one [1, 2] from the first glance – maybe if I get some more sleep?

[1]: https://github.com/python/cpython/blob/3.13/Lib/collections/...

[2]: https://github.com/python/cpython/blob/3.13/Lib/typing.py#L2...

Re: The first year of free-threaded Python

#236

Post by duped »

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…

Tbh if you're optimizing python code you've already lost

Re: The first year of free-threaded Python

#237

Post by Izkata »

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…

There's already a global:

  import gc
  gc.disable()
So I imagine putting more in there to remove objects from the tracking.

Re: The first year of free-threaded Python

#238

Post by kstrauser »

zahlman wrote: post #233
kstrauser wrote: post #226

Earlier quoted context omitted.

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…

You'd presumably need to do something involving weakrefs, since it would be really bad if you told Python that the elements can be GCd at all (never mind whether it can be done all at once) but someone else had a reference. Or completely rearchitect the language to have a model of automatic (in the C sense) allocation. I can't see that ever happening.

I don't think either of those are true. I'm not arguing against cleaning up objects during the normal runtime. What I'd like is something that would avoid GC'ing objects one-at-a-time at program shutdown.

I've had cases where it took Python like 30 seconds to exit after I'd slurped a large CSV with a zillion rows into RAM. At that time, I'd dreamed of a way to tell Python not to bother free()ing any of that, just exit() and let Linux unmap RAM all at once. If you think about it, there probably aren't that many resources you actually care about individually freeing on exit. I'm certain somewill will prove me wrong, but at a first pass, objects that don't define __del__ or __exit__ probably don't care how you destroy them.

Re: The first year of free-threaded Python

#239

Post by kstrauser »

duped wrote: post #236
kstrauser wrote: post #226

Earlier quoted context omitted.

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…

Tbh if you're optimizing python code you've already lost

Run along.

Re: The first year of free-threaded Python

#240

Post by kstrauser »

zahlman wrote: post #231
kstrauser wrote: post #124

Earlier quoted context omitted.

I haven’t been using it that much longer than you, and I agree with most of what you’re saying, but I’d characterize it differently. Python has a lot of solid workarounds for avoid threading because until now Python threading has absolutely sucked. I had naively tried to use it to make a CPU-bound workload twice as fast and soon realized the implications of the GIL, so I threw all that code away and made it multiproc…

> That sucked in its own way because I had to serialize lots of large data structures to pass around, so 2x the cores got me about 1.5x the speed and a warmer server room. In many cases you can't reasonably expect better than that ( https://en.wikipedia.org/wiki/Amdahl's_law ). If your algorithm involves sharing "large data structures" in the first place, that's a bad sign.

That's true, but you can sometimes get a whole lot closer if you can share state between threads. Sometimes you can't help the size of the data. Maybe you have a thread reading frames from a video and passing them to workers for analysis. You might get crazy IO contention if you pass around "foo.vid;frame222" and "foo.vid;frame223" to the workers and make them retrieve that data themselves.

There may be another way to skin that specific cat. My point isn't to solve one specific problem, but to say that some problems are just inherently large. And with Python, today, if those workers are CPU-bound in Python-land, that means running separate processes and passing large hunks of state around (or shoving it through SHM; same idea, just a different way of passing state).

Post reply on HN