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

201–210 of 302 posts

Re: The first year of free-threaded Python

#201

Post by morningsam »

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…

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

Re: The first year of free-threaded Python

#202

Post by kccqzy »

EGreg wrote: post #149

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

It's only a mostly solved problem for concurrent I/O heavy workloads. It's not solved in the Python world for parallel CPU-bound workloads.

Re: The first year of free-threaded Python

#203

Post by kstrauser »

dhruvrajvanshi wrote: post #172
kstrauser wrote: post #143

Earlier quoted context omitted.

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

> 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. Fucking hell bud :D

Tell me I'm wrong! :D

Re: The first year of free-threaded Python

#204

Post by ori_b »

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…

As another example: I run https://shithub.us with shell scripts, serving a terabyte or so of data monthly (mostly due to AI crawlers that I can't be arsed to block).

I'm launching between 15 and 3000 processes per request. While Plan 9 is about 10x faster at spawning processes than Linux, it's telling that 3000 C processes launching in a shell is about as fast as one python interpreter.

Re: The first year of free-threaded Python

#205

Post by nothrabannosir »

biorach wrote: post #153
nothrabannosir wrote: post #148

Earlier quoted context omitted.

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.

ah ok, sorry. I thought you were saying that they tried an EEE play on ActiveX. You meant they used ActiveX in an EEE play in the browser wars.

Honestly I kept it vague because I didn't actually know so your call-out was totally valid. I know it better now than without your clarification so thanks :+1:

Re: The first year of free-threaded Python

#206

Post by fredoralive »

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.

Python runs on other operating systems, like NT, where AIUI processes are rather more heavyweight.

Not all use cases of Python and Windows intersect (how much web server stuff is a Windows / IIS / SQL Server / Python stack? Probably not many, although WISP is a nice acronym), but you’ve still got to bear it in mind for people doing heavy numpy stuff on their work laptop or whatever.

Re: The first year of free-threaded Python

#207

Post by JacobHenner »

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.

VSCode displaced Atom, pre-GitHub acquisition, by building on top of Atom's rendering engine Electron.

Re: The first year of free-threaded Python

#209

Post by zahlman »

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.

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__` rather than `__main__`, allowing the programmer to distinguish. (Being able to distinguish is of course necessary here, to avoid making a fork bomb - since the top-level code runs automatically and `if __name__ == '__main__':` is normally top-level code.)

But also keep in mind that cleanup for a Python process also takes time, which is harder to trace.

Refs:

https://docs.python.org/3/library/multiprocessing.html#conte... https://stackoverflow.com/questions/72497140

Re: The first year of free-threaded Python

#210

Post by frollogaston »

notpushkin wrote: post #177
tomrod wrote: post #105

Earlier quoted context omitted.

I love learning from folks on HN -- thanks! Will check it out.

Take a look at https://capnproto.org/ as well, while at it. Neither solve the copying problem, though.

Ah, I forgot capnproto doesn't let you edit a serialized proto in-memory, it's read-only. In theory this should be possible as long as you're not changing the length of anything, but I'm not surprised such trickery is unsupported.

So this doesn't seem like a versatile solution for sharing data structs between two Python processes. You're gonna have to reserialize the whole thing if one side wants to edit, which is basically copying.

Post reply on HN