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

141–150 of 302 posts

Re: The first year of free-threaded Python

#141

Post by weakfish »

pphysch wrote: post #116
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.

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.

Is there any news from FastAPI folks and/or Gunicorn on their support?

Re: The first year of free-threaded Python

#142

Post by rfoo »

celeritascelery wrote: post #98
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…

> 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 want to run constantly. So, someone did it!

Yet, there's a pip maintainer who actively sabotages free-threading work. Nice.

Re: The first year of free-threaded Python

#143

Post by kstrauser »

biorach wrote: post #138
kstrauser wrote: post #135

Earlier quoted context omitted.

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 think it’s supremely risky to hitch your wagon to their tech or services OK, finally, yes, this is very true, for specific parts of their tech. But banging on about EEE just distracts from this, more important message. > Make it increasingly hard to use for FOSS development by starting to add barriers a little at a time. ....and now you've lost me again

Note I wasn’t the one who said EEE upstream. I was just replying to the thread.

Hanlon’s razor is a thing, and I generally follow it. It’s just that I’ve seen Microsoft make so many “oops, our bad!” mistakes over the years that purely coincidentally gave them an edge up over their competition, that I tend to distrust such claims from them.

I don’t feel that way about all corps. Oracle doesn’t make little mistakes that accidentally harm the competition while helping themselves. No, they’ll look you in the eye and explain that they’re mugging you while they take your wallet. It’s kind of refreshingly honest in its own way.

Re: The first year of free-threaded Python

#144

Post by kstrauser »

oblio wrote: post #139
kstrauser wrote: post #119

Earlier quoted context omitted.

That’s only reasonable if you believe you can only distrust one company at a time. I distrust every one you mentioned there, for different reasons, in different ways. I don’t think that Apple is trying to exclusively own the field of programming tools to their own profit, nor do I think that Facebook is. I don’t think Apple is trying to own all data about every human. I don’t think Microsoft is trying to force all ve…

Yet I only ever see these tired EEE memes for Microsoft when Chrome is basically the web, for example.

I don’t know what to tell you, except that you obviously haven’t read a lot of my stuff on that topic. (Not that I would expect anyone to have, mind you. I’m nobody.) I agree with you. I only use Chrome when I must, like when I’m updating a Meshtastic radio and the flasher app doesn’t run on Firefox or Safari.

I’m not anti-MS as much as anti their behavior, whoever is acting that way. This thread is directly related to MS so I’m expressing my opinion on MS here. I’ll be more than happy to share my thoughts on Chrome in a Google thread.

Re: The first year of free-threaded Python

#145

Post by spookie »

bayindirh wrote: post #42
HDThoreaun wrote: post #36

Earlier quoted context omitted.

> But a simple solution to address your fears: simply don't use threads. You'll be fine. Im not worried about new code. Im worried about stuff written 15 years ago by a monkey who had no idea how threads work and just read something on stack overflow that said to use threading. This code will likely break when run post-GIL. I suspect there is actually quite a bit of it.

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.

Re: The first year of free-threaded Python

#146

Post by frollogaston »

tomrod wrote: post #101
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.

I can fit a lot of json into bytes/strings though?

If all your state is already json-serializable, yeah. But that's just as expensive as copying if not more, hence what cjbgkagh said about flatbuffers.

Re: The first year of free-threaded Python

#147

Post by fjasdfas »

pphysch wrote: post #116
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.

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.

Re: The first year of free-threaded Python

#148

Post by nothrabannosir »

biorach wrote: post #127
nothrabannosir wrote: post #123

Earlier quoted context omitted.

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

> A classic example is ActiveX. Nah, even that was based on earlier MS technologies - OLE and COM A good starter list of EEE plays is on the wikipedia page: https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...

Funny you linked that page because that’s where I got activex from :D

> Examples by Microsoft

> Browser incompatibilities

> The plaintiffs in an antitrust case claimed Microsoft had added support for ActiveX controls in the Internet Explorer Web browser to break compatibility with Netscape Navigator, which used components based on Java and Netscape's own plugin system.

Re: The first year of free-threaded Python

#149

Post by EGreg »

I thought this was mostly a solved problem.

  Fibers
  Green threads
  Coroutines
  Actors
  Queues (eg GCD)
  …
Basically you need to reason about what your thing will do.

Separate concerns. Each thing is a server (microservice?) with its own backpressure.

They schedule jobs on a queue.

The jobs come with some context, I don’t care if it’s a closure on the heap or a fiber with a stack or whatever. Javascript being single threaded with promises wastefully unwinds the entire stack for each tick instead of saving context. With callbacks you can save context in closures. But even that is pretty fast.

Anyway then you can just load-balance the context across machines. Easiest approach is just to have server affinity for each job. The servers just contain a cache of the data so if the servers fail then their replacements can grab the job from an indexed database. The insertion and the lookup is O(log n) each. And jobs are deleted when done (maybe leaving behind a small log that is compacted) so there are no memory leaks.

Oh yeah and whatever you store durably should be sharded and indexed properly, so practicalkt unlimited amounts can be stored. Availability in a given share is a function of replicating the data, and the economics of it is that the client should pay with credits for every time they access. You can even replicate on demand (like bittorrent re-seeding) to handle spikes.

This is the general framework whether you use Erlang, Go, Python or PHP or whatever. It scales within a company and even across companies (as long as you sign/encrypt payloads cryptographically).

It doesn’t matter so much whether you use php-fpm with threads, or swoole, or the new kid on the block, FrankenPHP. Well, I should say I prefer the shared-nothing architecture of PHP and APC. But in Python, it is the same thing with eg Twisted vs just some SAPI.

You’re welcome.

Re: The first year of free-threaded Python

#150

Post by tinix »

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

shared memory only works on dedicated hardware.

if you're running in something like AWS fargate, there is no shared memory. have to use the network and file system which adds a lot of latency, way more than spawning a process.

copying processes through fork is a whole different problem.

green threads and an actor model will get you much further in my experience.

Post reply on HN