5 ms·
Well this release will break any code that uses threads. The goal of this particular release is to work for thread-free programs.
by Kranar 3y ago
Well this release will break any code that uses threads. The goal of this particular release is to work for thread-free programs.
- ollien 3y agoHow do single-threaded programs benefit from a lack of GIL?
- protomikron 3y agoThey don't.
- gtirloni 3y agoIt could remove the locking/unlocking operations.
- Retr0id 3y agoDoesn't removing the GIL imply adding back new, more granular locks?
- fiddlerwoaroof 3y agoSort of, but the biased reference counting scheme they’re using avoids a lot of locks for the common case.
- sapiogram 3y agoRemoving the GIL requires more locking/unlocking operations. For single-threaded program, it's a performance penalty on average: https://peps.python.org/pep-0703/#performance https://peps.python.org/pep-0703/#performance
- Kranar 3y agoThey don't benefit much from a lack of GIL, perhaps a small reduction in overhead. This feature is a first step towards being able to disable the GIL completely. It is intended to be implemented in a very conservative manner, bit by bit and so for this first step it should work for thread free code.
- kjqgqkejbfefn 3y agoDisabling the GIL can unlock true multi-core parallelism for multi-threaded programs, but this requires code to be restructured for safe concurrency, which isn't that difficult it seems: > When we found out about the “nogil” fork of Python it took a single person less than half a working day to adjust the codebase to use this fork and the results were astonishing. Now we can focus on data acquisition system development rather than fine-tuning data exchange algorithms. https://peps.python.org/pep-0703/ https://peps.python.org/pep-0703/
- kjqgqkejbfefn 3y ago>We frequently battle issues with the Python GIL at DeepMind. In many of our applications, we would like to run on the order of 50-100 threads per process. However, we often see that even with fewer than 10 threads the GIL becomes the bottleneck. To work around this problem, we sometimes use subprocesses, but in many cases the inter-process communication becomes too big of an overhead. To deal with the GIL, we usually end up translating large parts of our Python codebase into C++. This is undesirable because it makes the code less accessible to researchers.
- actionfromafar 3y agoMaybe they should look in to translating parts of their code base to Shedskin Python. It compiles (a subset of) Python to C++.
- logicchains 3y agoHow's it different from Cython, which compiles a subset of Python to C or C++?
- actionfromafar 3y agoShedskin has stricter typing, and about 10-100 times performance vs Cython.
- TylerE 3y agoSpeed. Admittedly not quite as much so the way this patch is implemented, since it just short circuits the extra function calls, doesn’t omit them entirely.
- 0cf8612b2e1e 3y agoRemoving the GIL results in slower execution. Without the guarantees of single thread action, the interpreter needs to utilize more locks under the hood.
- TylerE 3y agoNot in single threaded code.
- 0cf8612b2e1e 3y agoUmm, yes it does? For the longest time, Guido’s defense for the GIL was that all previous efforts resulted in an unacceptable hit to single threaded performance. Read PEP-703 (https://peps.python.org/pep-0703/#performance https://peps.python.org/pep-0703/#performance) where the performance hit is currently 5-8%
- TylerE 3y agoThat's to make it thread safe without the GIL. If you only care about single thread there's all kinds of stuff you can do.
- jononor 3y agoHow to ensure there are no other threads, confidently enough that one can turn thread safety off?
- Kranar 3y agoFrom when I was reading the proposal, the idea is that until a C extension is loaded, you can assume that there are no other threads. Then when a module is loaded, by default you assume that it uses threads but modules that are thread free can indicate that using a flag, so if a module indicates it's thread free then you continue running without the thread safety features.
- OskarS 3y agoReally, any code? I thought they were adding fine-grained locks to the python objects themselves? Are you saying that if I share a python list between two threads and modify it on one and read it on the other, I can segfault python?
- Kranar 3y agoWith this particular release, yes it will segfault. But down the road what you state is correct, this is just a first step towards that goal.
- thibaut_barrere 3y agoCouldn’t it work if each threads only touch thread-specific data structures?
- neilkk 3y agoThis isn't correct. TFA said that small threaded programs had been run successfully, but that the test suite broke in asyncio. Async I/O and threads are two different things, and either can be present in real code without the other.
- wolletd 3y ago"small threaded programs had been run successfully" I have ran a lot of programs containing race conditions successfully many times until I ran into an issue.
- Kranar 3y agoNot quite sure what your comment means exactly or how it implies what I said is incorrect. At any rate, test_asyncio contains a lot of tests that involve threads and specifically thread safety between coroutines and those tests fail. As far as async I/O and threads being distinct, I mean sure that is true of a lot of features but people mix features together and mixing asyncio with threads will not work with this particular release.
- neilkk 3y ago> this release will break any code that uses threads. > small threaded programs had been run successfully The second obviously contradicts the first, doesn't it? > mixing asyncio with threads will not work with this particular release. That's a very different claim to the first, and one that no longer conflicts with the second, isn't it?