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

41–50 of 302 posts

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

#41

Post by kroolik »

threatripper wrote: post #35
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…

You have a single big data structure that can't be shared easily between multiple processes. Can't you use multiprocessing with that? Maybe mapping the data structure to a file and mmapping that in multiple processes? Maybe wrapping the whole thing in database instead of just using one huge nested dictionary? To me multi-threading sounds so much less painful than all the alternatives that I could imagine. Just adding…

One annoying part with multiprocessing in Python is that you could abuse the COW mechanism to save on loading time when forking. But Python stores ref counters together with objects so every single read will bust your COW cache.

Now, you wanted it simple, but got to fight with the memory model of a language that wasn't designed with performance in mind, for programs whose focus wasn't performance.

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

#42

Post by threatripper »

fbdab103 wrote: post #11

Still not encouraged by the no-GIL, "We don't want another Python 2->3 situation", yet very little proffered on how to avoid that scenario. More documentation on writing thread-safe code, suggested tooling to lint for race conditions (for whatever it is worth), discussions with popular C libraries, dedicated support channels for top tier packages, what about the enormous long-tail of abandoned extensions which still…

I was assuming that no-GIL will only be enabled if all imported libraries support it. That means that they are marked as no-GIL ready and otherwise the import would throw an exception. Not sure how it is implemented now but that sounded very reasonable to me. The no-GIL compatible code would start with the core libraries and then expand from that. Using legacy libraries just means that you have to revert back to GIL-mode. Any no-GIL enabled library should 100% still function in GIL-mode, so I don't expect the Python 2->3 transition situation to repeat.

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

#43

Post by sidlls »

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.

It's (likely) much less expensive (in many ways, not just financially) to employ a larger number of python programmers than a smaller number of them skilled in a language more appropriate for the use case. Engineer flexibility, salary costs, maintenance/correctness concerns with implications for development time, etc., are all factors here. The technical choice of "python or not python" is rarely the only--or even most important--choice to make.

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

#44

Post by rrishi »

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 am not too deeply experienced with Python so forgive my ignorance.

But I am curious to understand why you were not able to utilize the concurrency tools provided in Python.

A quick google search gave me these relevant resources

1. An intro to threading in Python (https://realpython.com/intro-to-python-threading/#conclusion...)

2. Speed Up Your Python Program With Concurrency (https://realpython.com/python-concurrency/)

3. Async IO in Python: A Complete Walkthrough (https://realpython.com/async-io-python/)

Forgive me for my naivety. This topic has been bothering me for quite a while.

Several people complain about the lack of threading in Python but I run into plenty of blogs and books on concurrency in Python.

Clearly there is a lack in my understanding of things.

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

#45

Post by oivey »

fbdab103 wrote: post #38
Jtsummers wrote: post #34

Earlier quoted context omitted.

> writing multithreaded code will get harder because you'll likely need to handle concurrency issues yourself I'd phrase this differently: Writing correct multithreaded code will be just as challenging (or not, depending on the person and their comfort with concurrent and parallel code development) as before, but now you won't be able to get away with sloppy multithreaded code that relied on the GIL to not break.

It was correctly written to the invariant promises of the platform at the time. If Python is altering the deal, that does not suddenly make the library writer at fault.

There seems to be some confusion here. The GIL is not an invariant of Python that makes your code thread safe. Python is not altering the deal. You can still use threads to write concurrent code in Python today, and you'll still run into all of the classic concurrency related bugs.

People just mostly don't bother writing threaded code in Python today because it provides no performance benefit. That may change, and it very likely will expose many threading bugs that already exist in many libraries that just have never been found.

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

#46

Post by antod »

brightball wrote: post #36
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…

This is actually one of the reasons I was drawn to Ruby over Python. Ruby also has the GIL but jRuby is an excellent option when needed.

I wonder what lead to JRuby attracting support while Jython not? I know the Jython creator went on to other things (was it eg IronPython for dotnet?). I suppose it was the inverse with dotnet - eg IronPython surviving while IronRuby seems dead.

Is it just down to corporate sponsorship?

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

#47

Post by aardvark179 »

rrishi wrote: post #44
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 am not too deeply experienced with Python so forgive my ignorance. But I am curious to understand why you were not able to utilize the concurrency tools provided in Python. A quick google search gave me these relevant resources 1. An intro to threading in Python ( https://realpython.com/intro-to-python-threading/#conclusion... ) 2. Speed Up Your Python Program With Concurrency ( https://realpython.com/python-concur…

Threading in Python is fine if your threads are io bound or spend their time in a C extension which releases the GIL, if you are bound then the GIL means effectively one thread can run at a time and you gain no advantage from multiple threads.

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

#48

Post by teraflop »

rrishi wrote: post #44
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 am not too deeply experienced with Python so forgive my ignorance. But I am curious to understand why you were not able to utilize the concurrency tools provided in Python. A quick google search gave me these relevant resources 1. An intro to threading in Python ( https://realpython.com/intro-to-python-threading/#conclusion... ) 2. Speed Up Your Python Program With Concurrency ( https://realpython.com/python-concur…

The whole point of the GIL is that even if you use Python's threading or asyncio, you don't get any benefits from scaling beyond a single CPU core, because all of your threads (or coroutines) are competing for a single lock. They run "concurrently", but not actually in parallel. The pages you linked explain this in more detail.

In theory, multiprocessing could allow you to distribute the workload, but in a situation like OP describes -- just serving API requests based on a data structure -- the overhead of dispatching requests would likely be bigger than the cost of just handling the request in the first place. And your main server process is still a bottleneck for actually parsing the incoming requests and sending responses. So you're unlikely to see a significant benefit.

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

#50

Post by [deleted] »

rrishi wrote: post #44
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 am not too deeply experienced with Python so forgive my ignorance. But I am curious to understand why you were not able to utilize the concurrency tools provided in Python. A quick google search gave me these relevant resources 1. An intro to threading in Python ( https://realpython.com/intro-to-python-threading/#conclusion... ) 2. Speed Up Your Python Program With Concurrency ( https://realpython.com/python-concur…

[deleted]
Post reply on HN