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

Unlocking Python's Cores:Energy Implications of Removing the GIL

arxiv.org

Post reply on HN
Print view View original

61–70 of 111 posts

Re: Unlocking Python's Cores:Energy Implications of Removing the GIL

#61

Post by bigstrat2003 »

PaulHoule wrote: post #37
dr_zoidberg wrote: post #29

Earlier quoted context omitted.

If we go by Microsofts 2020 account of 1 billion devices running Windows 10 [0], and assume all those are running some kind of electron app (or multiple?) you easily get your gigawatt by just saving 1 watt across each device (on average). I suspect you'd probably go higher than 1 gigawatt, but I'm not sure as far as making another order of magnitude. I also think the noisy fan on my notebook begs to differ and maybe…

There are 30,000 different x-platform GUI frameworks and they all share one attribute: (1) they look embarrassingly bad compared to Electron or Native apps and they mostly (2) are terrible to program for. I feel like I never wasting my time when I learn how to do things with the web platform because it turns out the app I made for desktop and tablet works on my VR headset. Sure if you are going to pay me 2x the marke…

> Every time I do a shoot-out of Electron alternatives Electron wins and it is not even close

Only if you're ok with giving your users a badly performing application. If you actually care about the user experience, then Electron loses and it's not even close.

Re: Unlocking Python's Cores:Energy Implications of Removing the GIL

#63

Post by heavyset_go »

LtWorf wrote: post #48
devrimozcay wrote: post #4

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

But python can fork itself and run multiple processes into one single container. Why would there be a need to run several containers to run several processes? There's even the multiprocessing module in the stdlib to achieve this.

Threads are cheap, you can do N work simultaneously with N threads in one process, without serialization, IPC or process creation overhead.

With multiprocessing, processes are expensive and work hogs each process. You must serialize data twice for IPC, that's expensive and time consuming.

You shouldn't have to break out multiple processes, for example, to do some simple pure-Python math in parallel. It doesn't make sense to use multiple processes for something like that because the actual work you want to do will be overwhelmed by the IPC overhead.

There are also limitations, only some data can be sent to and from multiple processes. Not all of your objects can be serialized for IPC.

Re: Unlocking Python's Cores:Energy Implications of Removing the GIL

#64

Post by rpcope1 »

devrimozcay wrote: post #4

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

> observability tooling for Python evolving

As much as I dislike Java the language, this is somewhere where the difference between CPython and JVM languages (and probably BEAM too) is hugely stark. Want to know if garbage collection or memory allocation is a problem in your long running Python program? I hope you're ready to be disappointed and need to roll a lot of stuff yourself. On the JVM the tooling for all kinds of observability is immensely better. I'm not hopeful that the gap is really going to close.

Re: Unlocking Python's Cores:Energy Implications of Removing the GIL

#65

Post by philsnow »

kevincox wrote: post #40
devrimozcay wrote: post #4

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

This is surely why Facebook was interested in funding this work. It is common to have N workers or containers of Python because you are generally restricted to one CPU core per Python process (you can get a bit higher if you use libs that unlock the GIL for significant work). So the only scaling option is horizontal because vertical scaling is very limited. The main downside of this was memory usage. You would have t…

> The main downside of this was memory usage. You would have to load all of your code and libraries N types and in-process caches would become less effective.

You can load modules and then fork child processes. Children will share memory with each other (if they need to modify any shared memory, they get copy-on-write pages allocated by the kernel) and you'll save quite a lot on memory.

Re: Unlocking Python's Cores:Energy Implications of Removing the GIL

#66

Post by philsnow »

kccqzy wrote: post #53
LtWorf wrote: post #48

Earlier quoted context omitted.

But python can fork itself and run multiple processes into one single container. Why would there be a need to run several containers to run several processes? There's even the multiprocessing module in the stdlib to achieve this.

Forking and multi threading do not coexist. Even if one of your transitive dependencies decides to launch a thread that’s 99% idle, it becomes unsafe to fork.

Fork-then-thread works, does it not?

Re: Unlocking Python's Cores:Energy Implications of Removing the GIL

#67

Post by heavyset_go »

inejge wrote: post #55
LtWorf wrote: post #47

Earlier quoted context omitted.

Qt does exist. It's not difficult.

Qt costs serious money if you go commercial. That might not be important for a hobby project, but lowers the enthusiasm for using the stack since the big players won't use it unless other considerations compel them.

Depends on the modules and features you use, or where you're deploying, otherwise it's free if you can adhere to the LGPL. Just make it so users can drop in their own Qt libs.

Re: Unlocking Python's Cores:Energy Implications of Removing the GIL

#68

Post by rpcope1 »

kccqzy wrote: post #53
LtWorf wrote: post #48

Earlier quoted context omitted.

But python can fork itself and run multiple processes into one single container. Why would there be a need to run several containers to run several processes? There's even the multiprocessing module in the stdlib to achieve this.

Forking and multi threading do not coexist. Even if one of your transitive dependencies decides to launch a thread that’s 99% idle, it becomes unsafe to fork.

Im curious as to the down votes on this. It's absolutely true, and when I was maintaining a job runner daemon that ran hundreds of thousands of who knows what Python tasks/jobs a day on some shared infra with arbitrary code for a certain megacorp from 2016-2020 or so, this was one of insidious and ugly failure modes to go debug and handle. The docs really make it sound like you can mix threading and multiprocessing but you can never really completely ensure that threading and then bare fork will ever be safe, period. It's really irritating that the docs would have you believe that this is OK or safe, but is in keeping with the Python philosophy of trying to hide the edge of the blade you're using until it's too late and you've cut the shit out of yourself.

Re: Unlocking Python's Cores:Energy Implications of Removing the GIL

#69

Post by kevincox »

philsnow wrote: post #65
kevincox wrote: post #40

Earlier quoted context omitted.

This is surely why Facebook was interested in funding this work. It is common to have N workers or containers of Python because you are generally restricted to one CPU core per Python process (you can get a bit higher if you use libs that unlock the GIL for significant work). So the only scaling option is horizontal because vertical scaling is very limited. The main downside of this was memory usage. You would have t…

> The main downside of this was memory usage. You would have to load all of your code and libraries N types and in-process caches would become less effective. You can load modules and then fork child processes. Children will share memory with each other (if they need to modify any shared memory, they get copy-on-write pages allocated by the kernel) and you'll save quite a lot on memory.

Yes, this can help a lot, but it definitely isn't perfect. Especially since CPython uses reference counting it is likely that many pages get modified relatively quickly as they are accessed. Many other GC strategies are also pretty hostile to CoW memory (for example mark bits, moving, ...) Additionally this doesn't help for lazy loaded data and caches in code and libraries.

Re: Unlocking Python's Cores:Energy Implications of Removing the GIL

#70

Post by rpcope1 »

philsnow wrote: post #66
kccqzy wrote: post #53

Earlier quoted context omitted.

Forking and multi threading do not coexist. Even if one of your transitive dependencies decides to launch a thread that’s 99% idle, it becomes unsafe to fork.

Fork-then-thread works, does it not?

But not the reverse, if its a bare fork and not strictly using basically mutex and shared resource free code (which is hard), and there's little or no warning lights to indicate that this is a terrible idea that fails in really unpredictable and hard to debug ways.
Post reply on HN