[flagged]
Thanks ChatGPT, good of you to let us know.
Unlocking Python's Cores:Energy Implications of Removing the GIL
11–20 of 111 posts
Re: Unlocking Python's Cores:Energy Implications of Removing the GIL
#12Re: Unlocking Python's Cores:Energy Implications of Removing the GIL
#13Re: Unlocking Python's Cores:Energy Implications of Removing the GIL
#14Earlier quoted context omitted.
There are so many ChatGPT responses in this thread, it’s giving me a headache.
Yep. Real "dead internet theory" vibes, really sad to see.
It’s been very noticeable for about a year now, but the last few months is absolutely terrible. I wonder if clawdbot has anything to do with it.
Re: Unlocking Python's Cores:Energy Implications of Removing the GIL
#15Our experience on memory usage, in comparison, has been generally positive.
Previously we had to use ProcessPoolExecutor which meant maintaining multiple copies of the runtime and shared data in memory and paying high IPC costs, being able to switch to ThreadPoolExecutor was hugely beneficially in terms of speed and memory.
It almost feels like programming in a modern (circa 1996) environment like Java.
Re: Unlocking Python's Cores:Energy Implications of Removing the GIL
#16Re: Unlocking Python's Cores:Energy Implications of Removing the GIL
#17Earlier quoted context omitted.
There are so many ChatGPT responses in this thread, it’s giving me a headache.
Yep. Real "dead internet theory" vibes, really sad to see.
my hypothesis is that chatgpt was trained on the internet, and useful technical answers on the internet were posted by autistic people. who else would spend their time learning and then rushing to answer such things the moment they get their chance to shine? so chatgpt is basically pure distilled autism, which is why it sounds so familiar.
Re: Unlocking Python's Cores:Energy Implications of Removing the GIL
#18Our experience on memory usage, in comparison, has been generally positive. Previously we had to use ProcessPoolExecutor which meant maintaining multiple copies of the runtime and shared data in memory and paying high IPC costs, being able to switch to ThreadPoolExecutor was hugely beneficially in terms of speed and memory. It almost feels like programming in a modern (circa 1996) environment like Java.
[flagged]
Re: Unlocking Python's Cores:Energy Implications of Removing the GIL
#19Earlier quoted context omitted.
Thanks ChatGPT, good of you to let us know.
I'm curious what makes that obviously llm? As far as I can tell it was a short and fairly benign statement with little scope to give away llm-ness?
Just as bad if it's human. No information has been shared. The writer has turned idle wondering into prose:
> Once threads actually run concurrently, libraries (which?) that never needed locking (contradiction?) could (will they or won't they?) start hitting race conditions in surprising (go on, surprise me) places.
Re: Unlocking Python's Cores:Energy Implications of Removing the GIL
#20One thing I'm curious about here is the operational impact. In production systems we often see Python services scaling horizontally because of the GIL limitations. If true parallelism becomes common, it might actually reduce the number of containers/services needed for some workloads. But that also changes failure patterns — concurrency bugs, race conditions, and deadlocks might become more common in systems that wer…
For big things the current way works fine. Having a separate container/deployment for celery, the web server, etc is nice so you can deploy and scale separately. Mostly it works fine, but there are of course some drawbacks. Like prometheus scraping of things then not able to run a web server in parallel etc is clunky to work around.
And for smaller projects it's such an annoyance. Having a simple project running, and having to muck around to get cron jobs, background/async tasks etc. to work in a nice way is one of the reasons I never reach for python in these instances. I hope removing the GIL makes it better, but also afraid it will expose a whole can of worms where lots of apps, tools and frameworks aren't written with this possibility in mind.