Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What's up, Python? The GIL removed, a new compiler, optparse deprecated

bitecode.dev

Post reply on HN
Print view View original

71–80 of 302 posts

Re: What's up, Python? The GIL removed, a new compiler, optparse deprecated

#71

Post by RayVR »

nwallin wrote: post #53
wmwmwm wrote: post #14

Historically I’ve written several services that load up some big datastructure (10s or 100s of GB), then expose an HTTP API on top of it. Every time I’ve done a quick implementation in Python of a service that then became popular (within a firm, so 100s or 1000s of clients) I’ve often ended up having to rewrite in Java so I can throw more threads at servicing the requests (often CPU heavy). I may have missed somethin…

> I may have missed something but I couldn’t figure out how to get the multi-threaded performance out of Python Multiprocessing. The answer is to use the python multiprocessing module, or to spin up multiple processes behind wsgi or whatever. > Historically I’ve written several services that load up some big datastructure (10s or 100s of GB), then expose an HTTP API on top of it. Use the python multiprocessing module…

Multiprocessing is not a real solution, it’s a break-glass procedure when you just need to throw some cores at something without any hope for reliability. Unless something has changed since I used python, it is essentially a wrapper on Fork.

This means you need to deal with stuck/dead processes. I’ve used multiprocessing extensively and once you hit a certain amount of usage, even in a pool, you just get hangs and unresponsive processes.

I’ve also written a huge amount of Cython wrapped c++ code which releases the GIL. This never hangs and I can multithread there all I want without issue.

Re: What's up, Python? The GIL removed, a new compiler, optparse deprecated

#72

Post by ctoth »

School-Cotton wrote: post #15
masklinn wrote: post #9

Earlier quoted context omitted.

Even then the GIL can cause issues, concerns of PyTorch are specifically one of the motivations of the PEP, and one of the reasons Meta / FB really really wants this: > In PyTorch, Python is commonly used to orchestrate ~8 GPUs and ~64 CPU threads, growing to 4k GPUs and 32k CPU threads for big models. While the heavy lifting is done outside of Python, the speed of GPUs makes even just the orchestration in Python not…

I feel like orchestrating thousands of GPUs is such a niche use case that it’s fair to expect the people wanting to do it to learn a more suited language, rather than ruining Python for everyone else.

I notice you used the strong emotional word "ruining" when talking about the effect on Python of this change. Why do you believe an obscure runtime concurrency detail which will make more things possible will "ruin" the language?

Now match and :=? Those definitely ruin the language. ;-)

But seriously, relax, nothing bad is happening here. It's not just people who have to use the torch launcher who have been bitten by Python's currently-terrible multicore story. I've been a Python programmer for 15 years and I think this is a wonderful change.

Re: What's up, Python? The GIL removed, a new compiler, optparse deprecated

#73

Post by qbasic_forever »

andrewstuart wrote: post #3

From reading the thread on HN the other day, it sounds like removing the GIL isn't really of much value. Maybe for somewhat obscure multithreading cases. Is that right?

Correct, it will help with CPU-limited, embarrassingly parallelizable problems... which are much less common than you think.

Re: What's up, Python? The GIL removed, a new compiler, optparse deprecated

#74

Post by nickcw »

cvnmalk wrote: post #28

Which, except for optparse, was all on the front page yesterday. So optparse is deprecated. More work I guess apart from auditing extensions for threading. Life is great in the Python treadmill.

I've tried to love argparse but it is so complicated. I always have to read the docs each time I use it.

getopt has its own brutal simplicity.

Re: What's up, Python? The GIL removed, a new compiler, optparse deprecated

#75

Post by mike_ivanov »

__d wrote: post #67
jeremycarter wrote: post #19

Earlier quoted context omitted.

Similar experience. Even with multi process and threads python is slow, very slow. Java, Go and .NET all provide a very performant out of box experience.

Python is both an interpreter, and quite dynamic. Both of these lead to lower performance when compared to less dynamic, compiled solutions. All of Java, Go, and .NET are compiled and (much) less dynamic. This is absolutely an expected outcome.

"absolutely an expected outcome."

Good day. Is it the right time to talk to you about Common Lisp?

Re: What's up, Python? The GIL removed, a new compiler, optparse deprecated

#76

Post by qbasic_forever »

hanniabu wrote: post #16

Will writing multithreaded code become easier? Or will the developer UX remain the same?

No it will be the same level of skill and difficulty to do correct shared memory multithreaded programming. You'll have to manually manage locks and reason about potential for deadlock or other race conditions.

If anything it will be harder as the implicit serialization of the GIL being removed means libraries might suddenly develop race conditions that you've never experienced or seen before, likely causing spectacular crashes and undefined behavior or bugs.

Re: What's up, Python? The GIL removed, a new compiler, optparse deprecated

#77

Post by ActorNightly »

andrewstuart wrote: post #3

From reading the thread on HN the other day, it sounds like removing the GIL isn't really of much value. Maybe for somewhat obscure multithreading cases. Is that right?

The big thing that is driving no GIL is the speed up of processing data for ML, which afaik cannot be done with multiprocessing.

Re: What's up, Python? The GIL removed, a new compiler, optparse deprecated

#78

Post by toasted-subs »

RayVR wrote: post #71
nwallin wrote: post #53

Earlier quoted context omitted.

> I may have missed something but I couldn’t figure out how to get the multi-threaded performance out of Python Multiprocessing. The answer is to use the python multiprocessing module, or to spin up multiple processes behind wsgi or whatever. > Historically I’ve written several services that load up some big datastructure (10s or 100s of GB), then expose an HTTP API on top of it. Use the python multiprocessing module…

Multiprocessing is not a real solution, it’s a break-glass procedure when you just need to throw some cores at something without any hope for reliability. Unless something has changed since I used python, it is essentially a wrapper on Fork. This means you need to deal with stuck/dead processes. I’ve used multiprocessing extensively and once you hit a certain amount of usage, even in a pool, you just get hangs and un…

I’m not a huge fan of Cython and the like. It seems to be more natural to open a tcp connection to a c/c++ program and let that do the heavy lifting. Anything else seems like not a proper UNIX style solution.

Re: What's up, Python? The GIL removed, a new compiler, optparse deprecated

#79

Post by Jtsummers »

qbasic_forever wrote: post #70
wmwmwm wrote: post #14

Historically I’ve written several services that load up some big datastructure (10s or 100s of GB), then expose an HTTP API on top of it. Every time I’ve done a quick implementation in Python of a service that then became popular (within a firm, so 100s or 1000s of clients) I’ve often ended up having to rewrite in Java so I can throw more threads at servicing the requests (often CPU heavy). I may have missed somethin…

Are you just reading from this data structure? If so I wouldn't do any locking or threading, I'd just use asyncio to serve up read requests to the data and it should scale quite well. Multithreading/processing is best for CPU limited workloads but this sounds like you're really just IO-bound (limited by the very high IO of reading from that data structure in memory). If you're allowing writes to the shared data struc…

> I'd just use asyncio to serve up read requests to the data and it should scale quite well.

Quoting GP:

>> often CPU heavy

We have to take their word for it that it's actually CPU heavy work, but if they're not lying and not mistaken then asyncio would do nothing for them.

Re: What's up, Python? The GIL removed, a new compiler, optparse deprecated

#80

Post by ActorNightly »

jeremycarter wrote: post #19
wmwmwm wrote: post #14

Historically I’ve written several services that load up some big datastructure (10s or 100s of GB), then expose an HTTP API on top of it. Every time I’ve done a quick implementation in Python of a service that then became popular (within a firm, so 100s or 1000s of clients) I’ve often ended up having to rewrite in Java so I can throw more threads at servicing the requests (often CPU heavy). I may have missed somethin…

Similar experience. Even with multi process and threads python is slow, very slow. Java, Go and .NET all provide a very performant out of box experience.

3.11 and on should be comparable to Java for most use cases with multiprocessing (set up correctly of course)
Post reply on HN