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

81–90 of 111 posts

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

#81

Post by influx »

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…

I would have thought most of those would have been moved to async Python by now.

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

#83

Post by liuliu »

nijave wrote: post #59
p_m_c wrote: post #42

> Similarly, workloads where threads frequently access and modify the same objects show reduced improvements or even degradation due to lock contention. Perhaps I'm stating the obvious, but you deal with this with lock-free data structures, immutable data, siloing data per thread, fine-grain locks, etc. Basically you avoid locks as much as possible.

It'd be nice if Python std lib had more thread safe primitives/structures (compared to something like Java where there's tons of thread safe data structures) Imo the GIL was used as an excuse for a long time to avoid building those out.

> It'd be nice if Python std lib had more thread safe primitives/structures (compared to something like Java where there's tons of thread safe data structures)

Hence why basic Python structures under free-threaded Python are all thread-safe structures, and explains why they are slower than GIL-variant.

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

#84

Post by LtWorf »

akdev1l wrote: post #74
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.

Why is it unsafe?

In general only the thread calling fork() gets forked, so unless you call exec() soon after, there are a lot of complications with signals, shared memory.

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

#85

Post by LtWorf »

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.

I'm sure microsoft and slack have sufficient funds for a commercial Qt license.

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

#86

Post by LtWorf »

wiseowise wrote: post #58
LtWorf wrote: post #47

Earlier quoted context omitted.

Qt does exist. It's not difficult.

...which is the same as Flutter. Both don't use native UI toolkits (though Qt doesn't use Skia, I'll give you that (Flutter has Impeller engine in the works)). And Qt has much worse developer experience and costs money.

Qt costs money if you for some reason insist on static linking AND use all the fancy components, the core stuff is all LGPL.

Anyway it does look native and it is way faster than electron, which also doesn't look native so I don't understand why it's a problem for Qt but not for electron.

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

#87

Post by LtWorf »

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.

I'm replying to a person that scales python by running several containers instead of 1 container with several python processes.

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

#88

Post by LtWorf »

influx wrote: post #81
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…

I would have thought most of those would have been moved to async Python by now.

async python still uses a single thread for the main loop, it just hides non blocking IO.

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

#89

Post by josefx »

kccqzy wrote: post #72
philsnow wrote: post #66

Earlier quoted context omitted.

Fork-then-thread works, does it not?

If you have enough discipline to make sure you only create threads after all the forking is done, then sure. But having such discipline is harder than just forbidding fork or forbidding threads in your program. It turns a careful analysis of timing and causality into just banning a few functions.

Can't you check what threads are active at the time you fork?

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

#90

Post by connorboyle »

heavyset_go wrote: post #63
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.

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

It makes sense to me that a program currently written using multiple processes would now be re-written to use multiple truly parallel threads. But it seems very odd to suggest (as your grandparent comment does) that a program currently run in multiple containers would likely be migrated to run on multiple threads.

In other words, I imagine anyone who cares about the overhead from serialization, IPC, or process creation would already be avoiding (as much as possible) using containers to scale in the first place.

Post reply on HN