3 ms·
Both is not really on the table. Getting rid of the Gil will slow down single threaded code.
by slashdev 3y ago
Both is not really on the table. Getting rid of the Gil will slow down single threaded code.
- rowanG077 3y agoWhy would removing the GIL slow down single threaded code?
- edgyquant 3y agoI believe without a GIL objects need to be thread safe which comes at a price
- viraptor 3y agoYou still need to run the same memory management/accounting for all the objects as when you run multithreaded, because at any point a new thread may be started. And it takes more time to make all MT access safe then to prevent other threads from running.
- Austizzle 3y agoAs far as I know, in order to make everything thread safe in the same way the gil did, they need to add locks in a lot of places to make sure that no two objects can be modified at the same time. Adding those locks will slow down execution
- Jtsummers 3y agoNo-GIL forces the addition of locks and other concurrency controls into the execution path of single-threaded code that's not there now. It's the same kind of hit you get going from thread-unsafe code (hopefully intended for single-threaded execution) to thread-safe in any other project (since, well, it's the same; the GIL means they could write code with single-threaded assumptions). Checking and taking locks is not a free action.
- rowanG077 3y agoI thought the point of No-GIL was to force users of python to provide proper locking.
- Jtsummers 3y agoTo achieve no-GIL, libraries and extensions along with the underlying language implementation will need to add in the proper locking. For users, it'll be mixed. Users writing single-threaded code shouldn't have to change a single line of code, but they'll see (sans the concurrent efforts to speed up the underlying implementation) slower performance due to everything done to achieve no-GIL (the actual net effect will be a performance boost due to that concurrent effort over time). If they're writing multi-threaded code, then they should be writing it to be threadsafe now, not assuming that the GIL will protect them (because it doesn't guarantee it now anyways). So nothing should actually change for most users of Python if they're writing correct code today.
- kortex 3y agoPython's reference counting garbage collector would also need concurrency controls.
- Jtsummers 3y agoThe last numbers I saw put the performance penalty of no-GIL at under 10%, so both are still on the table since Python has a lot of single-threaded performance left to recover. You can get both a much faster-than-current Python in single-threaded and real threads.
- alfalfasprout 3y agoYep and when the faster cpython team gets to implementing advanced JITing (which GVR has said is planned) that'll be huge.
- slashdev 3y agoObviously you can recover it, but they will Be a performance hit. Single threaded without GIL will always be slower than with it. I’ll be surprised if they can keep it to only 10%. It will depend on the workload and there will Be some pathological cases.
- alfalfasprout 3y ago> Both is not really on the table Incorrect. > Getting rid of the Gil will slow down single threaded code Correct. But that's before fastercpython improves single threaded performance closing that gap if not reversing it.