4 ms·
Speed. 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.
by TylerE 3y ago
Speed. 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.