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

Intent to approve PEP 703: making the GIL optional

discuss.python.org

Post reply on HN
Print view View original

231–240 of 513 posts

Re: Intent to approve PEP 703: making the GIL optional

#231

Post by AlphaSite »

KeplerBoy wrote: post #227
n2d4 wrote: post #66

Earlier quoted context omitted.

It's only about performance. asyncio is still inherently single-threaded, and hence also single core. multiprocessing is multi-core and hence better for performance, but each process is relatively heavy and there's additional overhead to shared memory. GIL multi-threading is both single-core and difficult to use correctly. No-GIL multi-threading is multi-core, though difficult to use. I don't know the Python implemen…

Even with multithreading Python will still be slow. It's not like singlethreaded Python can keep up with singlethreaded C or even JS. This will just allow people to waste even more compute resources to get somewhat quick results from Python instead of doing the right thing. From an ecological viewpoint this PEP will be disastrous and keep entire power plants online.

Python is also getting a JIT, they’re pursuing performance on all axis.

Re: Intent to approve PEP 703: making the GIL optional

#233

Post by fred123 »

slt2021 wrote: post #78
miraculixx wrote: post #74

Earlier quoted context omitted.

Fully agree. People put far too much emphasis & expectations on the "free" part in "free multithreading".

even if they get "free multithreading" with no-GIL, their system eventually will overgrow one beefy machine and will need to be deployed across a fleet of 10/100/1000 machines. at which point you lose benefit of no-GIL, because you now have to introduce redis and kafka into the system

Why? On AWS you can rent a 24 TB, 500 core machine. Almost all problems are smaller than that so don’t need to scale to more than one machine.

Building applications that run on multiple machines is at least one order of magnitude more complex and thus slower (in development velocity), so needlessly building an application to work distributedly is just bad engineering.

Re: Intent to approve PEP 703: making the GIL optional

#234

Post by miraculixx »

trwsxcn wrote: post #14
tremon wrote: post #12

I know they say specifically that they don't want a repeat of the Python3 transition scenario, but the approach they're taking now still veers eerily close to that path, at least it looks that way to me. A lot will depend on the Python community and the distribution channels. I could see the community struggling to adopt it in a timely fashion, or distributions jumping the gun (Ubuntu, Fedora, Anaconda). Maybe it's t…

Yes, it will resemble the 2to3 scenario. Corporations that pledge support will mechanically convert some projects (pestering the actual developers or threaten with forks?), bugs will be ironed out by the actual, unpaid developers over years. But apparently Python needs some "success" and this makes a good bullet point. Correctness does not really matter in the Python world.

Is it success though?

Re: Intent to approve PEP 703: making the GIL optional

#235

Post by AlphaSite »

slt2021 wrote: post #73
n2d4 wrote: post #66

Earlier quoted context omitted.

It's only about performance. asyncio is still inherently single-threaded, and hence also single core. multiprocessing is multi-core and hence better for performance, but each process is relatively heavy and there's additional overhead to shared memory. GIL multi-threading is both single-core and difficult to use correctly. No-GIL multi-threading is multi-core, though difficult to use. I don't know the Python implemen…

I would argue that if you have large concurrency and shared complex state - you better off use kafka and redis/memcached as a shared state - and design proper fan-out. This design scales much better for systems that will eventually overgrow one big machine. the No-GIL pytohn will be of no use, when you need to deploy your app across 100s machines. I understand people want to take advantage of all cores etc, but at la…

There are a lot of performance sensitive codebases where something like this would destroy performance, it works well for shared nothing parallelism, but the moment you have shared state it kinda falls over.

Re: Intent to approve PEP 703: making the GIL optional

#236

Post by fred123 »

miraculixx wrote: post #91
slt2021 wrote: post #78

Earlier quoted context omitted.

even if they get "free multithreading" with no-GIL, their system eventually will overgrow one beefy machine and will need to be deployed across a fleet of 10/100/1000 machines. at which point you lose benefit of no-GIL, because you now have to introduce redis and kafka into the system

I kept making this point as well as the other arguments above (and others did too) in the Core Dev discussion group. Unfortuately to no avail. To be sure I am not a core dev.

Do you think Meta (Instagram) are pushing GIL removal and Cinder for no reason? They clearly have that scale and still benefit from faster single machine performance

Re: Intent to approve PEP 703: making the GIL optional

#237

Post by AlphaSite »

commonlisp94 wrote: post #53
jmount wrote: post #46

Why would you even want a no-GIL Python? Java and C showed how much more effort it takes to maintain slower thread safe code for no real benefit. Parallelize at the fork level or at the isolated numeric library level.

Exactly. I think a lot of the negativity about GIL comes from a misunderstanding about forking processes. If python is being used as a scripting language, and spawning other tools, you're already getting free multi-core. A similar misunderstanding exists about SQLite and concurrency.. but that's a topic for another time.

Forking had a ton of its own downsides, it’s not a free lunch either, from poor ergonomics to communications overhead it works well for somethings and very poorly for others.

Re: Intent to approve PEP 703: making the GIL optional

#238

Post by fred123 »

slt2021 wrote: post #67
dragonwriter wrote: post #62

Earlier quoted context omitted.

> is there any use case of No-GIL which is not solved by multiprocessing ? Anything that benefits from both parallelism and replacing IPC overhead with shared data between parallel tasks.

but it would incur overhead of concurrency control: mutex, locks, semaphores. I dont believe python will ever have atomic operations, even if it had - they still incur significant overhead for concurrency control. sharing state between threads is such a narow niche use case, this pattern is practically solved by memcached/redis for larger scale python based systems

> sharing state between threads is such a narow niche use case

It is the norm. „Kafka scale“ problems are not the norm.

Re: Intent to approve PEP 703: making the GIL optional

#239

Post by AlphaSite »

catnibbler wrote: post #112

Is it really too late to not do this ? The only reason to get rid of the GIL is to help threading, but that's not a thing we should be doing. Threads need to just die, and be replaced by something less idiotic. Seriously, having the CPU run fragments of your program at random, so that all the previously ordered pieces are now contending with each other and even themselves ? How can anyone not see that this is the stu…

Python already has threads, they just have huge downsides in their current form, so this ship has long since sailed.

Re: Intent to approve PEP 703: making the GIL optional

#240

Post by miraculixx »

Galanwe wrote: post #140
miraculixx wrote: post #79

Earlier quoted context omitted.

Yes, used for decades - and for good reason and benefit. No, no the same thing. Sharing objects between processes is not easily achieved for various reasons (at least in Python). It would be easier to get it in multithreading with an arena based allocation model where objects live in a shared or non-shared area of memory. Also it's not my idea. I am just advocating it as the better model for Python to advance to. It…

> No, no the same thing. Well to me it is the same thing. Two threads sharing state through a common heap, or two processes sharing state through a shared memory is pretty much indistinguishable, at least on Linux. The question is not multithreading or multiprocessing anymore, the difference to me is more semantic than real. The question is then just how these threads/processes communicate. I would argue that shared…

I agree, actually.

It's just that (some) people really want multithreading. And with that Python had the rare chance to say, ok you'll get it, but we will make it safe by default.

Now they said ok you get it, even though it's a big risk, we hope it'll work. If not, we'll take it back.

In what world is "taking back" even an option?

Post reply on HN