Hacker News Reader

Comment by JulianWasTaken | Hacker News Reader

This is not true. There have been plenty of successful attempts to remove the GIL, including from CPython. It's not impossibly hard to do so by a long shot.

The GIL is an optimization though, and so the performance hit from removing it on single threaded code is prohibitive. You can watch any of David Beazley's talks on the GIL for more info.

View on HN

I stand corrected. Still, saying they are going to remove the GIL without addressing the challenges faced by other people who did the same - most notably the performance hit - makes me skeptical as to their ability to fulfill their promises.

Prohibitive is too strong I think. The patch to 1.4 discussed in a blog post by Beazley came with a 2x slow down, but that was an initial patch without much work on optimization. Besides that, I think 2x slowdown isn't that bad considering the language is not used for its raw efficiency anyway.

Well, the only reason to remove it is to run multiple Python threads in parallel for efficiency...so efficiency is definitely the top concern here.

No the reason to remove it is to get parallelism from threads. Once you have parallelism, you can overcome a 2x slow down for a single thread by using more cores.

If 99% of your codebase uses one thread, then no, a 2x slow down is not acceptable, even if you can overcome it by using more cores.

Remember, the ideas was not to have CPython and CPython-without-GIL, it was to have one unified GIL-less CPython.

For that, a 2x performance drop would not be acceptable for most code.

But 2x was just with the initial, non-optimized patch. A language like Java seems to perform quite well even with fine-grained locking, so it's possible.

And I don't see why performance is suddenly used as a deal breaker for a language primarily used for scripting and other non-CPU-bound purposes.

I speculate that the performance issue wasn't really the most important reason for rejecting the patch, but more so not wanting to deal with the complexity of maintaining the patch. It's a shame because the future is definitely going to have lots of cores, and not all problems are well-suited to multiprocessing.

>And I don't see why performance is suddenly used as a deal breaker for a language primarily used for scripting and other non-CPU-bound purposes.

People want to use Python for lots of CPU bound processes. A big Python niche is numeric and scientific computing.

You say that it is "primarily used for scripting and other non-CPU-bound purposes", but this is also a consequence of it being slow. If it was faster it would open MORE uses. LUA and C# got the games action. Go gets attention on the networking apps end, etc...

The difference is that Java's memory model was designed from the ground up to work with multiple threads. Python's semantics are that only 1 thread is running at any point in time. Keeping that illusion while running multiple threads in parallel is what causes the huge overhead. The alternative is to do away with CPython semantics, but that would break a ton of existing code.

Reply on news.ycombinator.com