> > Message: 1 > Date: Tue, 9 Aug 2011 15:31:47 +0600 > From: ???? ????????? <socketpair at gmail.com> > To: python-dev at python.org > Subject: [Python-Dev] GIL removal question > Message-ID: > <CAEmTpZGe2J6poDUW3sihHS3LHDdQ3cq5gWqfty_=z5W8R0R3-Q at mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > Probably I want to re-invent a bicycle. I want developers to say me > why we can not remove GIL in that way: > > 1. Remove GIL completely with all current logick. > 2. Add it's own RW-locking to all mutable objects (like list or dict) > 3. Add RW-locks to every context instance > 4. use RW-locks when accessing members of object instances You're forgetting step 5. 5. Put fine-grain locks around all reference counting operations (or rewrite all of Python's memory management and garbage collection from scratch). > Only one reason, I see, not do that -- is performance of > singlethreaded applications. After implementing the aforementioned step 5, you will find that the performance of everything, including the threaded code, will be quite a bit worse. Frankly, this is probably the most significant obstacle to have any kind of GIL-less Python with reasonable performance. Just as an aside, I recently did some experiments with the fabled patch to remove the GIL from Python 1.4 (mainly for my own historical curiosity). On Linux, the performance isn't just slightly worse, it makes single-threaded code run about 6-7 times slower and threaded code runs even worse. So, basically everything runs like a dog. No GIL though. Cheers, Dave
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4