Hacker News Reader

Comment by viraptor | Hacker News Reader

Interesting that you're looking for those improvements in CPython. From your list (IMO): speed and multicore are going to stay where they are in CPython - GIL is unlikely to be removed, because it's basically part of the behaviour right now. There were a few attempts, but it seems nobody even tries anymore. (and I'm fine with that) Maybe pypy, grumpy, or others will do this instead.

I'm not sure why you expect GPU from the python itself though. That's completely up to libraries and they can exist for either 2.x or 3.x. Was there ever a CPython GPU related project?

View on HN

The GIL is encoded into practically every C API of the interpreter. It's not going away in CPython, and at the very least any Python implementation supporting CPython extensions will have a global lock for calls into extensions.

And even if (there were patches for removing the GIL already around in the 90s): All of the approaches and patches shown so far significantly degraded single-threaded performance, which matters to way more applications than the GIL, which typically is not a significant limit to using multiple cores/processors.

"Teh GIL" is a very, very overblown issue, and is -- I don't want to be condescending here, but well -- usually brought up by people that have little experience writing software that makes effective use of multiple-many cores.

Yeah, you are a bit condescending here. Part of the topic was multicore. If you're interested in actually cutting down the data transfers without resorting to explicit shared memory, GIL and threads are very much on topic. Whether it's an overblown issue depends specifically on your workload and reasons why you're still using python if you care about multicore.

Actually, between PyPi and "The Gilectomy", there two serious projects to get rid of it, the latter with core developer support: https://us.pycon.org/2016/schedule/presentation/2101/

I attended this talk, and it was really great. PyPi is pursuing software transactional memory, which is massively difficult to implement. The Gilectomy approach is much more community oriented, and focuses on the transition.

Put a bit differently: it's easy to remove the GIL safely, it just incurs a non-trivial performance penalty and breaks C extensions, so the Gilectomy effort is around a combination of removing or avoiding that penalty if you're not multi-threading, and smoothly transitioning C extensions. After that talk, removing the GIL looks inevitable.

Reply on news.ycombinator.com